size_t in a struct

[bwaichu]

To avoid padding in structures, where is the best place to put size_t
variables?

According the faq question 2.12 (http://c-faq.com/struct/padding.html),
it says:

"If you're worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."

So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long? If it does,
then size_t still wouldn't be larger than a pointer on the system,
right? But where should I put size_t in relation to other integer
declarations? Should I all ways assume size_t is an unsigned long when
building structures?

Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?

Thanks.

[Simon Biber]

bw*****@yahoo.c om wrote:

To avoid padding in structures, where is the best place to put size_t
variables?

According the faq question 2.12 (http://c-faq.com/struct/padding.html),
it says:

"If you're worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."

In general this is good advice. But different types have different sizes
on different compilers. If minimising the space is important, you would
have to customise the layout for each compiler you port the code to.

So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.

Not necessarily! size_t may be equivalent to unsigned short, unsigned
int, unsigned long, unsigned long long or some other
implementation-defined integer type. It may even be longer than unsigned
long long, but no longer than uintmax_t.

In addition, the pointer may be of various different sizes. Testing
three different compilers I happen to have here, I can have 16-bit,
32-bit and 64-bit pointers to char.

In most cases you'll find that char* and size_t have the same size on
any given system. One exception that comes to mind is Turbo C's 'huge'
memory model, where char* is 4 bytes but size_t is 2.

However, will size_t ever become an unsigned long long? If it does,
then size_t still wouldn't be larger than a pointer on the system,
right? But where should I put size_t in relation to other integer
declarations? Should I all ways assume size_t is an unsigned long when
building structures?

If it matters that much to you, you could test the size on the
particular system and generate the required code.

Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?

A single Buffer2_t struct will probably have the same amount of padding
as two Buffer_t structs, since it is basically just two of the same
thing, one after the other. Putting the 'name' member at the end
probably wouldn't make any difference to the overall size.

--
Simon.

[Gordon Burditt]

>According the faq question 2.12 (http://c-faq.com/struct/padding.html),

>it says:

"If you're worried about wasted space, you can minimize the effects of
padding by ordering the members of a structure based on their base
types, from largest to smallest."

I don't agree with this, and I don't think it will work, when
pointers are involved. For example, a short is more likely to be
smaller than a pointer to anything, even char. "pointer" isn't a
base type but things work better here if you assume it is.

>So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long? If it does,

Probably. It wouldn't surprise me on an architecture with 64-bit
pointers but an attempt to keep types like long the same as the
older legacy system keeps long at 32 bits.

>then size_t still wouldn't be larger than a pointer on the system,
right?

No guarantees, but it's a pretty safe bet. And the penalties for
losing the bet are minimal: structure padding wastes a bit of
memory but no undefined behavior.

>But where should I put size_t in relation to other integer
declarations ? Should I all ways assume size_t is an unsigned long when
building structures?

You may assume that size_t is slightly larger or slightly smaller
than an unsigned long for the purpose of the ordering. Alternating
size_t and unsigned long would tend to maximize padding if they
aren't the same size.

Assume size_t is slightly larger if you think your code will more
likely run on newer systems where size_t and unsigned long long
might be 64 bit. Assume size_t is slightly smaller than unsigned
long if your code will more likely run on older systems where size_t
might be 16 bits.

There are other places where you have similar problems, such as the
relative size of double and pointer or double and unsigned long
long.

Either way, it is virtually certain you WILL be wrong some of the
time. You can still try for being right a pretty good percentage
of the time.

>Now, if I made another structure:

typedef struct _Buffer2_t {

Buffer_t name;
char *buffer;
size_t size;

} Buffer2_t;

Is the above still the correct sequence to minimize padding?

There is no single correct sequence. That one is a reasonable
guess, though.

[bwaichu]

Simon Biber wrote:

So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.

Not necessarily! size_t may be equivalent to unsigned short, unsigned
int, unsigned long, unsigned long long or some other
implementation-defined integer type. It may even be longer than unsigned
long long, but no longer than uintmax_t.

So standard-wise, how do I handle size_t in structures to minmize
padding? Should size_t all ways follow after pointers in structures?
And if I have integers in the structure, where should I put size_t?

<OT>
According my style(9) man page, the suggestion is to:

"When declaring variables in structures, declare them sorted by use,
then
by size (largest to smallest), then by alphabetical order. "

This would lead to padding, right? But I would have to assume a size
for size_t to follow that style.
</OT>

Thanks.

[Chris Torek]

In article <11************ **********@k70g 2000cwa.googleg roups.com>
bw*****@yahoo.c om <bw*****@yahoo. comwrote:

>To avoid padding in structures, where is the best place to put size_t
variables?

This is not really predictable, because sizeof(size_t) is not
predictable. In general, though, size_t will be one of unsigned
int, unsigned long, or unsigned long long (it must always be
some unsigned type).

>... if I have the following:

typedef struct _Buffer_t {
char *buffer;
size_t size;
} Buffer_t;

In general, you (as a programmer) should avoid names starting
with underscore. (If you are an implementor -- the guy writing
the compiler -- you should use *only* names starting with
underscore, except when you know it is safe or required to
do otherwise.)

In particular, names that start with underscore followed by an
uppercase letter are always reserved to the implementor. *He* gets
to use names like _Buffer_t, so you must avoid them; he does *not*
get to use names like "Buffer", so you can use those. (Names
starting with one underscore and then a lowercase letter are only
"sometimes" reserved to the implementor. It is a lot easier,
though, to just avoid them all.)

Note that you can use the same tag for the structure and the
typedef (if you insist on using typedefs at all). See also
<http://web.torek.net/torek/c/types2.html>.

>I should have mimized padding since size_t is an unsigned long.
However, will size_t ever become an unsigned long long?

It might.

>If it does, then size_t still wouldn't be larger than a pointer
on the system, right?

It might, although this makes less sense in general. Note also
that some pointer types might be larger or smaller than other
pointer types: on old PR1ME machines, for instance, sizeof(char *)
was 6 but sizeof(int *) was 4.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[bwaichu]

Chris Torek wrote:

typedef struct _Buffer_t {
char *buffer;
size_t size;
} Buffer_t;

In general, you (as a programmer) should avoid names starting
with underscore. (If you are an implementor -- the guy writing
the compiler -- you should use *only* names starting with
underscore, except when you know it is safe or required to
do otherwise.)

In particular, names that start with underscore followed by an
uppercase letter are always reserved to the implementor. *He* gets
to use names like _Buffer_t, so you must avoid them; he does *not*
get to use names like "Buffer", so you can use those. (Names
starting with one underscore and then a lowercase letter are only
"sometimes" reserved to the implementor. It is a lot easier,
though, to just avoid them all.)

Note that you can use the same tag for the structure and the
typedef (if you insist on using typedefs at all). See also
<http://web.torek.net/torek/c/types2.html>.

So if I am writing a set of buffer functions to be used for an
application, and I want
to create my own type to be used throughout the code, I should avoid
using underscores.

Whenever I use typedefs, which is rare, I like to name the structure
the same name as the typedef. So would this be better form:

typedef struct buf {
char *buffer;
size_t size;
} Buf;

Thanks!

[Keith Thompson]

"bw*****@yahoo. com" <bw*****@yahoo. comwrites:

Simon Biber wrote:

So if I have the following:

typedef struct _Buffer_t {

char *buffer;
size_t size;

} Buffer_t;

I should have mimized padding since size_t is an unsigned long.

Not necessarily! size_t may be equivalent to unsigned short, unsigned
int, unsigned long, unsigned long long or some other
implementati on-defined integer type. It may even be longer than unsigned
long long, but no longer than uintmax_t.

So standard-wise, how do I handle size_t in structures to minmize
padding? Should size_t all ways follow after pointers in structures?
And if I have integers in the structure, where should I put size_t?

[...]

The standard doesn't guarantee anything in this area. It doesn't
define the relative sizes of char* and size_t, and it doesn't say much
about the relationship between size and alignment.

My advice: Declare the members in an order that makes sense, and let
the compiler worry about alignment issues.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Snis Pilbor]

bw*****@yahoo.c om wrote:

>
<OT>
According my style(9) man page, the suggestion is to:

"When declaring variables in structures, declare them sorted by use,
then
by size (largest to smallest), then by alphabetical order. "

This would lead to padding, right? But I would have to assume a size
for size_t to follow that style.
</OT>

Thanks.

Hmm, this is all very surprising to me: why on earth should the
structure layout depend on the order of the elements in the source? Is
there any reason to do this? Why don't compilers automatically
minimize the size of the structure, that seems like a no-brainer to me?
I can maybe see how it *might* be useful for the compiler to have the
freedom to sacrifice some size to put the most used element at the
beginning of the actual structure layout, just because then whenever
that element is called there's one less addition to perform.. I don't
understand how it could be beneficial to permute elements any further
beyond that though..

[Keith Thompson]

"Snis Pilbor" <sn********@yah oo.comwrites:

bw*****@yahoo.c om wrote:

><OT>
According my style(9) man page, the suggestion is to:

"When declaring variables in structures, declare them sorted by use,
then
by size (largest to smallest), then by alphabetical order. "

This would lead to padding, right? But I would have to assume a size
for size_t to follow that style.
</OT>

Hmm, this is all very surprising to me: why on earth should the
structure layout depend on the order of the elements in the source? Is
there any reason to do this? Why don't compilers automatically
minimize the size of the structure, that seems like a no-brainer to me?
I can maybe see how it *might* be useful for the compiler to have the
freedom to sacrifice some size to put the most used element at the
beginning of the actual structure layout, just because then whenever
that element is called there's one less addition to perform.. I don't
understand how it could be beneficial to permute elements any further
beyond that though..

The C standard requires the first member of a structure to be at
offset 0, and each following member to be at a higher offset than the
previous one.

(I personally wouldn't mind if the compiler were allowed to rearrange
structure members arbitrarily, with an optional directive to require
them to be laid out in declared order, but that's not what the
standard says.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"bw*****@yahoo. com" <bw*****@yahoo. comwrites:
[...]

So if I am writing a set of buffer functions to be used for an
application, and I want
to create my own type to be used throughout the code, I should avoid
using underscores.

You should avoid defining identifiers starting with underscores *at
all* (unless you're writing a C implementiaton) . There are limited
circumstances in which you can get away with it, but frankly it's
easier to avoid it altogether than to remember the rules.

Whenever I use typedefs, which is rare, I like to name the structure
the same name as the typedef. So would this be better form:

typedef struct buf {
char *buffer;
size_t size;
} Buf;

That's not the same name; "buf" and "Buf" are distinct identifiers.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.