Struct member management through functions

I'm making a library that's to be compiled by the user to both static and shared files (.a and .dll/.so). Padding in structs can vary if the compiler linking with the library is different than the one that built the library, and you can't portably make just some structs have 0 padding, so I'm leaving all struct member setting/retrieving and memory allocation for the structs as functions in the library—just as libpng does it.

I have a few functions:

void SetDERPFile(DERPFile * DERPFileInfo, uint32_t Options, uint32_t Param, uint32_t Value, ...);
void SetDERPFileOption(DERPFile * DERPFileInfo, uint32_t Param, uint32_t Value);
uint32_t GetDERPFileOption(const DERPFile * DERPFileInfo, uint32_t Param);

The first does the same as the second, but doesn't require 15 function calls to set 15 different variables in the struct.

And if you're wondering, here's the code to making a new DERPFile:

DERPFile * NewDERPFile(uint32_t Type)
{
    DERPFile *ptr = (DERPFile*) malloc(sizeof(DERPFile));
    if(ptr == NULL) return NULL;

    ptr->Type = Type;
    memset(ptr+4, 0, sizeof(DERPFile)-4);

    return ptr;
}

So I need a neat way to match a given Option argument with the offset and size of a DERPFile struct member. The best way to do this is with a const uint8_t DERPFile_offsets[] and a const uint8_t DERPFile_sizes[]. But am I really supposed to do *this*?

const uint8_t DERPFile_struct_offsets[] = {
    offsetof(DERPFile, FirstMember),
    offsetof(DERPFile, SecondMember),
    ...etc...
}

const uint8_t DERPFile_struct_sizes[] = {
    sizeof(DERPFile.FirstMember),
    sizeof(DERPFile.SecondMember),
    ...etc...
}

I'd be repeating the struct definition twice... Well, with the second table, I can simply supply the numerical constants instead of using sizeof, but the first requires offsetof() to take the struct padding into account.

Just wondering if there's any better way to do this so the people I'm working with don't laugh at my code.

Rewrite it in assembly.

>Wanted something portable
>>2

Just in need of a way to make a function that will "Set the 'n'th argument in this struct 'x' of type DERPFile to the given value of 'y'".

Why... why don't you just make the struct members public, and the users of the API can fill them how they please?
You're going to need to either release the source or make separate library builds for every platform you support anyway, so struct packing really shouldn't be an issue.

I'd imagine in some shitty interpreted language you could just do:

x.argument(n) = y;

Even with the arrays set up, I'd need a way to truncate the given Value to the correct size. If I just access it the way it is, it won't work on Big-Endian systems, like if I do this:

memcpy(DERPFileInfo+DERPFile_struct_offsets[Param], &Value, DERPFile_struct_sizes[Param]);

I'd need to specifically copy each byte, one at a time. Not through pointers, but by AND-masking and bit-shifting.

>>4
It *is* open source. Like I said in the opening post, the user compiles it for his own platform, keeps in somewhere, and includes in in another project by linking with either the .a or the .dll/.so and #including <libderp.h>.

Okay.
Well... there shouldn't be a problem to let the user fill out the struct's members themselves, instead of providing a helper function? Struct alignment still shouldn't be a problem.

If you insist on having a helper function for something that's just as easy to do manually, or if you're doing validation on it or something, you could use fifteen different functions. You could macro/template them out. You could spend hours agonising over how to do the pointer arithmetic in a cross-platform way. You could even just use a switch over the enum constant you pass. Whatever.

hibt

derp.itm
DERP(FirstMember)
DERP(SecondMember)

derp.c
const uint8_t DERPFile_struct_offsets[] = {
#define DERP(x) offsetof(DERPFILE, x),
#include "derp.itm"
#undef DERP
}

const uint8_t DERPFile_struct_sizes[] = {
#define DERP(x) sizeof(DERPFILE.x),
#include "derp.itm"
#undef DERP
}

I'm not even going to read your post because of all the DERP##shit going on, grow the fuck up.

>>9
fuck off and die textboardfag

yeah, fuck off and die derpboardfag

>>11
fuck you fagstorm

>>9
The invasion of the imageboard users. And here I thought we couldn't get any worse than the usual spammers.