Having to store size of structure in structure

[Markus]

Hi, all.

I've been doing some work with the Windows API (icky, real icky). Often times when setting the members of a structure, you have to also store the size of the structure; for example, the SECURITY_ATTRIB UTES structure. I don't understand why this needs to be done. If a function is expecting a SECURITY_ATTRIB UTES structure, shouldn't it know the size of it too, via sizeof(SECURITY _ATTRIBUTES)? Is there a purpose to this?

[weaknessforcats]

Which API is that?

[Markus]

Huh? The Windows API. I see this all over the place in the structures.

[weaknessforcats]

There are all kinds of Windows APIs.

SECURITY_ATTRIB UTES is used in CreateFile, CreatePipe, CreateProcess, RegCreateKeyEx and none of these require the sizeof the SECURITY_ATTRIB UTES struct.

It is true that inside SECURITY_ATTRIB UTES there is a pointer member for security descriptor and that member as an associated length member. But that's because security descriptors vary in length.

I couldn't find a Windows API function that needed the size of the SECURITY_ATTRIB UTES struct as an argument along with a pointer to the struct variable and I was hoping you could tell me which API calls were giving you grief so I could look them up.

[Markus]

No - there is no function causing me grief, hehe. I was just wondering why in a struct you'd have a reference to the size of that struct. Won't the size of the struct always be sizeof(struct)?

[donbock]

I can think of three reasons to embed the size of a structure within that structure:

1. The structure has variable length.
2. A copy of the structure might be passed between computers whose compilers have different type sizes. A size field mismatch guarantees the structure is unusable. The converse is not true.
3. A "magic number" indicating that the structure has been filled.

[weaknessforcats]

If you had something like this:

struct Stuff
{
   DWORD length;
   TrickyStruct* data;
};

the length might refer to the amount of data and not the sizeof TrickyStruct. Like data is an array of TrickyStruct and length is the number of elements. In C/C++ you cannot pass arrays to functions without decay of array . That is all that passes is the address of element 0. The number of elements is lost.

What you say is true. If you know the name of the type then you also can sizeof(type) and never need to supply the size as a separate value.

[Markus]

Thanks, guys. That about sums it up. Unfortunately I cannot select both of you for best answers :P

[Banfa]

You missed what I believe to be the real reason that the Windows API uses a size member in many structures which is that those Windows peeps use the size to differentiate between different versions of the structure as different versions of the WIN32 API get released.

This is most obvious in the bitmap structures but I always assumed it was the same else where.

As the WIN32 API gets developed the structures change, adding new data alters the size of the structure, and the size member is pretty much always the first in structures that use it, so the API call can find and examine the size member and then know which version of the structure has been passed to the function.

This allows the data in the structures to be altered as required (for instance when a new bitmap version is created) but the API call to remain backwardly compatible with any old compiled code.