Need clarity on structure alignment

[Keith Thompson]

I remember seeing something that left me with the impression that C (C++?)
guarantees that a struct will be aligned on a pointer-size boundary (using
the std mem mgr). (?) Something about 4-byte struct alignment (on a 32-bit
machine no doubt) sticks in my mind.

You remember incorrectly. There's no rule in C (or C++) about the
relationship between the alignment requirements for structs and
those for pointers. You may have seen something about a specific
implementation.

There is a rule that all pointers to structs have the same size
and alignment, but that refers to the pointer objects themselves,
not to the structs.

People in this thread have been asking the original poster why he's
concerned about alignment. You've been jumping in and "defending"
him, suggesting reasons he might care about it. I suggest you wait
for the OP himself to give his reasons. If he actually has specific
reasons, we can help him -- and knowing just why he's concerned about
alignment can help us to help him. But it's also quite possible
that he wrongly thinks he needs to worry about alignment, and that
in fact he can largely ignore the issue and still get working code.

 

[CBFalconer]

Little software can be created with just the standard. All else
is written to one or more platforms. I suspect that most compilers
offer some level of alignment control (they do on Wintel).

Horrors. What a misstatement. Most software CAN be written to the
standard. After that is done, and portable, the few things that
are impossible can be handled with implementation specific code.

Writing such code intelligently usually requires the writer be
familiar with the facilities of standard C.

 

[Eric Sosman]

You remember incorrectly. There's no rule in C (or C++) about the
relationship between the alignment requirements for structs and
those for pointers. You may have seen something about a specific
implementation.

The phrase "using the std mem mgr" suggests he may have
been thinking of malloc(), in which case he's sort of right:
If he uses malloc() to obtain memory for a struct, the memory
will in fact be properly aligned for storing a pointer. (Also
for storing a double, a union, a va_list, a time_t, and a
partridge in a pear tree, of course: malloc() memory is properly
aligned for *any* kind of data.)

 

[Antoninus Twink]

Horrors. What a misstatement. Most software CAN be written to the
standard.

Are you just a complete moron, or can it actually be the case that your
world experience extends no further than the four walls of your flooded
log cabin in Montana filled with dirty underwear, as you felt the need
to tell the world recently?

 

[Kenny McCormack]

Are you just a complete moron, or can it actually be the case that your
world experience extends no further than the four walls of your flooded
log cabin in Montana filled with dirty underwear, as you felt the need
to tell the world recently?

I think it is Maine, actually...

 

[Richard]

I think it is Maine, actually...

And there highlights the danger of posting "Off Topic". He should have
posted to a log cabin group where "experts" could have helped. "We" do
not discuss log cabine or Chuck's soiled lingerie here.

 

[Kenny McCormack]

And there highlights the danger of posting "Off Topic". He should have
posted to a log cabin group where "experts" could have helped. "We" do
not discuss log cabine or Chuck's soiled lingerie here.

Good point. I promise to do better in the future.

 

[Tony]

Maybe his code need not be portable beyond his development platform. Maybe
space and time efficiency is not important.

"if he doesn't care about either space or time why is he pissing
about with padding? Just write simple code and ship it."

You should ask him before assuming or suggesting that he need not worry
about padding/alignment/endianness/integer widths etc.

"Often people get sucked into worrying about "efficiency" without
really understanding why or even *what* it is."

The same can be said about portability. Moreso even.

Tony

 

[Tony]

Tony wrote:
...

There is no such requirement. 6.2.5p11 says "All pointers to structure
types shall have the same representation and alignment requirements
as each other." However, that applies to the struct pointers, not to the
structs themselves.

Perhaps arrays of structs? In C++ maybe. I read it again this week but I
can't remember where. Probably a research paper and I believed the writer.
If I see it again, post what I read that led me to believe that there was
some kind of guarantee for structure alignment (not the members in the
struct).

Tony

 

[Tony]

People in this thread have been asking the original poster why he's
concerned about alignment. You've been jumping in and "defending"
him, suggesting reasons he might care about it.

Well he might care about it!

Tony

 

[Tony]

news:[email protected]... [...]
Alignment requirements for different types vary depending on the
underlying hardware, and on what the compiler chooses to enforce.
I remember seeing something that left me with the impression that C
(C++?) guarantees that a struct will be aligned on a pointer-size
boundary (using the std mem mgr). (?) Something about 4-byte struct
alignment (on a 32-bit machine no doubt) sticks in my mind.

You remember incorrectly. There's no rule in C (or C++) about the
relationship between the alignment requirements for structs and
those for pointers. You may have seen something about a specific
implementation.

The phrase "using the std mem mgr" suggests he may have
been thinking of malloc(), in which case he's sort of right:
If he uses malloc() to obtain memory for a struct, the memory
will in fact be properly aligned for storing a pointer. (Also
for storing a double, a union, a va_list, a time_t, and a
partridge in a pear tree, of course: malloc() memory is properly
aligned for *any* kind of data.)

Indeed it is! If I find the passage and remember what I was actually
thinking, I'll post it.

Tony

 

[Tony]

Precisely: the compiler imposes those requirements, not the standard.

Gives the alignment/padding control you mean?

Code that is not intended to be portable can be written to rely upon a
knowledge of how alignment restrictions work on a particular
implementation. Portable code should be written to work correctly no
matter what the alignment restrictions are.

"Portable" is as "portable" needs to be. A lot of people take portability to
the extreme rather than being pragmatic about it. Define target platforms
first and then address portability. Indeed, if the target is too
broad/pie-in-the-sky, some of the potential target platforms may be dropped
or relegated to a separate build/product/release/version to avoid imposing
on the development of the baseline/primary platform(s).

Tony

 

[Tony]

Horrors. What a misstatement. Most software CAN be written to the
standard. After that is done, and portable, the few things that
are impossible can be handled with implementation specific code.

Writing such code intelligently usually requires the writer be
familiar with the facilities of standard C.

I left out the word 'significant' before the word 'software'. And yes, I
meant complete programs/systems of programs and not just some fraction of a
program.

Tony

 

[Keith Thompson]

I left out the word 'significant' before the word 'software'. And yes, I
meant complete programs/systems of programs and not just some fraction of a
program.

Few large programs are written in 100% standard C. (There *are*
exceptions.) But most programs, even large ones, can be written
*mostly* in standard C. With good design, the parts that depend on
system-specific features can be kept isolated, which makes porting
easier.

On the other hand, *some* programs are system-specific, and have no
real prospect of being ported. In cases like that, there's less
benefit in avoiding or isolating system-specific code.

 

[Keith Thompson]

Well he might care about it!

I suspect if he really cared about it, he'd have responded to one of
the several queries for more information by now.

 

[Tony]

I suspect if he really cared about it, he'd have responded to one of
the several queries for more information by now.

I meant at the time he posted it rather than "still now".

Tony

 

[Richard]

Few large programs are written in 100% standard C. (There *are*
exceptions.) But most programs, even large ones, can be written
*mostly* in standard C. With good design, the parts that depend on
system-specific features can be kept isolated, which makes porting
easier.

Unfortunately Keith, You, Heathfield and Chuck have determined that
"good design" are not ISO C and have deemed it off topic. Hence the,
belated, kick back.

On the other hand, *some* programs are system-specific, and have no
real prospect of being ported. In cases like that, there's less
benefit in avoiding or isolating system-specific code.

But they are still in C and good ISO C is applicable combined with
system specifics.

Hint : the garbage that the likes of Chuck post is applicable in about 1
in 100 cases. Good advice, however, about how best to utilise C to write
efficient and easily maintained code bases is applicable in ALL cases.

comp.lang.c

The hint is in the name.

 

[Tony]

Few large programs are written in 100% standard C. (There *are*
exceptions.) But most programs, even large ones, can be written
*mostly* in standard C.

GUI, threads, database, network... the std C portion looks relatively
miniscule.

With good design, the parts that depend on
system-specific features can be kept isolated, which makes porting
easier.

I consider std C/C++ (moreso C++ than C) a platform-specific thing to be
"isolated" also, though. YMMV.

Tony

 

[James Kuyper]

Gives the alignment/padding control you mean?

That happens to be the case, but it wasn't the issue I was addressing. I
was really responding to you pointing out that the standard is not
sufficient. It was never intended to be. If you need to know anything
about specific alignment requirements, the standard is not the place to go.

"Portable" is as "portable" needs to be. A lot of people take portability to
the extreme rather than being pragmatic about it. Define target platforms
first and then address portability.

That depends upon what you're doing. For instance, for most of the
programs I write, the primary issue is the data processing algorithm,
not the platform it runs on. That's mainly because they are batch jobs
reading input files, performing scientific data processing, and writing
output files. It is far more important that they produce results that
are accurate than that it produce results quickly. They have no GUI
interface, in fact they're not interactive at all. They don't do
anything in real-time. They happen to run under POSIX environments, but
none of my code depends upon that fact, even though our contract does
permit us to do so. They must be linked to three specific third-party
libraries, but are portable to any platform those libraries can be
ported to, which is a fairly broad list of platforms, and will continue
to be portable to them if the third-party vendors decide to broaden that
list. Those third party libraries, in particular, serve to insulate my
program from having to deal directly with the potential problems of
reading data on one platform that was written on a platform where
standard data types might have different representations or even
different sizes.

Platform-specific details are pretty much the last thing I have any
reason to consider. I realize that the priorities can be quite different
in other environments - but that's precisely my point.

 

[REH]

Unless you tell it specifically how to do padding/alignment. Whether #pragma
pack(1) will get you padding at the end of a struct or not is probably iffy.
Personally, I try to write structs that align nicely naturally without
padding. I wouldn't use just one 8-bit integer in a struct on a 32-bit
machine: I'd use 4 consequetive ones making the struct a multiple of 4
bytes.

For what purpose? That won't change the alignment of the structure,
nor cause other fields and objects to be misaligned.

REH