Structure size directives

[those who know me have no need of my name]

in comp.lang.c i read:

those who know me have no need of my name wrote:

I think he, and they, are mistaken. Code has quite different objectives
today than it used to. There was a time when memory was extremely
precious, and we took almost all options to economize it. Today, memory
(and disk storage) is cheap, and we use it freely. However nothing has
reduced the need for clear and understandable code.

c is still quite heavily used on platforms where memory remains tight,
though generally not quite so much as was once the case. still, if the
language (and thus this is really a comp.std.c issue more than clc)
provided a portable way of specifying that the struct should be as compact
as possible and that the platform demands for alignment be handled by the
compiler would mean even more code that would be portable, whether compiled
on a system with tight memory requirements or one with all the memory in
the world at hand. in the absence of such a facility we are left with
myriad implementation specific ways of accomplishing the same thing, and
(perhaps) fall-back code that handles it in the most general way possible
(it is hoped). much the same rationale applies as for the potentially
better code provided by memset or memcpy, else we should avoid them and
just write the loops.

BTW, please do not strip attributions for material you quote.

i stripped none. i added what i felt was appropriate -- as i feel i am not
speaking to a person as much as on a topic, already described in the
subject, and so where the content originated is the next most important.
even that isn't really worth mention, though even more stiff necked
responses would arrive had i provided nothing. i note that you stripped
what i provided, surely you should walk your own walk, neh? oh, and that
double sig ... never mind, i know how to ignore/trim such things without
whining at the author about minor infelicities.

 

[jacob navia]

Well, I usually assume that compiler writers/maintainers know far more C
than myself, but there has been some counter-examples by one person.

OP's lack of attention to detail is striking, instead of

"most compilers provide some way to do this"

it should have been

"common compiler extension ..."

Yeah, that is SO COMPLETELY different...

And when OP say:

"Note that under windows you must know this kind of stuff since windows
uses packed structures extensively."

I'm rather sure, he was ignorant to the fact that Windows may crash, when

#pragma pack (1)

is used, which is nothing less than shocking, when coming from someone
specializing on C compiler for this platform.

You are just talking nonsense...

1) Windows will not crash. Your program will
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.

 

[Tor Rustad]

Tor Rustad wrote:
[...]

And when OP say:

"Note that under windows you must know this kind of stuff since
windows uses packed structures extensively."

I'm rather sure, he was ignorant to the fact that Windows may crash, when

#pragma pack (1)

is used, which is nothing less than shocking, when coming from someone
specializing on C compiler for this platform.

You are just talking nonsense...

I was right then, you don't have a clue.

1) Windows will not crash. Your program will

There don't have to be a difference.

2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.

Why the heck, do you need some userland header file to hide behind?

As a compiler maintainer/writer, you should be the expert!

 

[Tor Rustad]

Tor Rustad wrote:

And when OP say:

"Note that under windows you must know this kind of stuff since
windows uses packed structures extensively."

I'm rather sure, he was ignorant to the fact that Windows may crash,
when

#pragma pack (1)

is used, [ ... ]

Windows or the offending program?

or both

 

[Kenneth Brody]

Tor Rustad wrote: [...]
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.

Why the heck, do you need some userland header file to hide behind?

As a compiler maintainer/writer, you should be the expert!

I'm not sure what you're saying here. Are you saying that the
compiler should have built-in hard-coded knowledge of all of the
Windows API structs and their packing needs, rather than having
"some userland header file" define them?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Tor Rustad]

Tor Rustad wrote: [...]
2) "You are rather sure I am ignorant of the fact..."
I am rather sure you are speculating about things you do
not know. Everywhere in the windows headers you will
find #pragma pack(1) or pragma pag(8) or some other
value.

Why the heck, do you need some userland header file to hide behind?

As a compiler maintainer/writer, you should be the expert!

I'm not sure what you're saying here. Are you saying that the
compiler should have built-in hard-coded knowledge of all of the
Windows API structs and their packing needs, rather than having
"some userland header file" define them?

No, I was saying that Jacob shouldn't argue his case, with what someone
else have done in their header files. His mistake is bad, since he is
supposed to be an expert, AFAIK a C compiler writer/maintainer,
particularly targeting Windows.

Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS or
Windows/x64.

The latter case is rather *important*, and people should very much
expect that a program executing in ring 0 (with misalignment bugs), will
crash the OS, while a programs in ring 3 crash themselves.

 

[Ben Pfaff]

Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.

This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").

 

[Tor Rustad]

This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. It does this for the calling process and any descendant
processes. This feature, which often dramatically reduces performance,
has not been implemented in 64-bit Windows. Thus, if your 32-bit driver
contains misalignment bugs, you will need to fix them when porting to
64-bit Windows."
- Microsoft, Kernel-Mode Driver Architecture: Windows DDK


IIRC, regarding MIPS, I have already given reference to the MSDN doc
elsewhere in this thread. <g>

 

[Ben Pfaff]

This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. [...]

Then it's Microsoft who is making the strange statement. From
Intel's documentation for the x86:

4.1.1. Alignment of Words, Doublewords, Quadwords, and
Double Quadwords

Words, doublewords, and quadwords do not need to be
aligned in memory on natural boundaries.

And from AMD's documentation for x86-64:

3.2.4 Data Alignment

...The x86-64 architecture does not impose data-alignment
requirements for accessing data in memory.

 

[jacob navia]

Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. [...]

Then it's Microsoft who is making the strange statement. From
Intel's documentation for the x86:

4.1.1. Alignment of Words, Doublewords, Quadwords, and
Double Quadwords

Words, doublewords, and quadwords do not need to be
aligned in memory on natural boundaries.

And from AMD's documentation for x86-64:

3.2.4 Data Alignment

...The x86-64 architecture does not impose data-alignment
requirements for accessing data in memory.

This is true if you do not use the ALIGNED instruction for reading
and writing to memory of course.

If you DO use them to load an xmm register with 128 bytes of data
the machine will trap if the data is not aligned to a 16 byte boundary.

If you never use those instructions there are no alignment problems.
Lcc-win never emits those instructions, but it could be that there
are instructions in system data structures that expect aligned data.
Until now I have never found those under windows.

Under linux, that is another thing. printf for instance, expects
16 byte boundary aligned floating point data and will happily
crash if that is not the case.

 

[Keith Thompson]

Under linux, that is another thing. printf for instance, expects
16 byte boundary aligned floating point data and will happily
crash if that is not the case.

<OT>
That appears not to be the case.

On a Linux x86 system, all three floating-point types have 4-byte
alignment; on a Linux x86-64 system, types float, double, and long
double have 4-, 8- and 16-byte size and alignment, respectively. But
on both systems, a floating-point object that's at an odd address can
be successfully printed.
</OT>

 

[Stephen Sprunk]

Like I have stated elsewhere, alignment faults will typically be
fixed (at a cost) by the kernel on Windows/x86, but not so, on
Windows/MIPS or Windows/x64.

This is a strange statement. On x86 and x86-64, the CPU does
not raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for
Windows CE (which is not usually just called "Windows").

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically
fixes kernel-mode memory alignment faults and makes them
invisible to the application. [...]

Then it's Microsoft who is making the strange statement. From
Intel's documentation for the x86:

Microsoft's comment likely refers to all Win32 platforms, not just x86. The
others (i.e. MIPS, PPC, Alpha) aren't as forgiving, so the OS has to fix up
unaligned memory accesses.

S

 

[Tor Rustad]

Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. [...]

Then it's Microsoft who is making the strange statement.

Well, I find your statement stranger. Both IA-64 and AMD64, can be
controlled by a kernel to raise exceptions on alignment bugs. When
Microsoft state that this is what Windows might be doing, I see no
reason to believe otherwise.

> From Intel's documentation for the x86:
>
> 4.1.1. Alignment of Words, Doublewords, Quadwords, and
> Double Quadwords
>
> Words, doublewords, and quadwords do not need to be
> aligned in memory on natural boundaries.

Here is what Intel say in "Itanium Architecture Software Developer’s
Manual Volume 2: System Architecture Rev. 2.2":

3.3.2 Processor Status Register (PSR)

[...]

"Alignment Check – When 1, all unaligned data memory references result
in an Unaligned Data Reference fault. When 0, unaligned data memory
references may or may not result in a Unaligned Data Reference fault."

[...]

"For IA-32 instructions, if PSR.ac is 1 an unaligned IA-32 data memory
reference raises an IA_32_Exception(AlignmentCheck) fault."

[...]

4.5 Memory Datum Alignment and Atomicity

"An aligned ld16 or st16 instruction is performed as an atomic 16-byte
memory reference. For these instructions, the address specified must be
16-byte aligned. Unaligned ld16 and st16 instructions result in an
Unaligned Data Reference fault regardless of the state of PSR.ac."

[...]

"When PSR.ac is 1, any Itanium data memory reference that is not aligned
on a boundary the size of the operand results in an Unaligned Data
Reference fault; e.g., 1, 2, 4, 8, 10, and 16-byte datums should be
aligned on 1, 2, 4, 8, 16, and 16-byte boundaries respectively to avoid
generation of an Unaligned Data Reference fault."

> And from AMD's documentation for x86-64:
>
> 3.2.4 Data Alignment
>
> ...The x86-64 architecture does not impose data-alignment
> requirements for accessing data in memory.

Regardning AMD, the "AMD64 Architecture Programmer’s Manual Volume 2:
System Programming. Pub. #24593":

"Alignment Mask (AM) Bit. Bit 18. Software enables automatic alignment
checking by setting the AM bit to 1 when eFLAGS.AC=1. Alignment checking
can be disabled by clearing either AM or eFLAGS.AC to 0. When automatic
alignment checking is enabled and CPL=3, a memory reference to an
unaligned operand causes an alignment-check exception (#AC)."

 

[jacob navia]

Well, I find your statement stranger. Both IA-64 and AMD64, can be
controlled by a kernel to raise exceptions on alignment bugs. When
Microsoft state that this is what Windows might be doing, I see no
reason to believe otherwise.

You are right, but if you do not want problems, just do not use
those instructions that provoke alignment faults...

Always a source of trouble.

 

[Ben Pfaff]

Ben Pfaff wrote:

Like I have stated elsewhere, alignment faults will typically be fixed
(at a cost) by the kernel on Windows/x86, but not so, on Windows/MIPS
or Windows/x64.
This is a strange statement. On x86 and x86-64, the CPU does not
raise a fault at all for most kinds of misaligned arguments, in
the operating mode usually used, typically at minimal cost. And
modern versions of Windows do not run on MIPS, except for Windows
CE (which is not usually just called "Windows").
Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. [...]

Then it's Microsoft who is making the strange statement.

Well, I find your statement stranger. Both IA-64 and AMD64, can be
controlled by a kernel to raise exceptions on alignment bugs. When
Microsoft state that this is what Windows might be doing, I see no
reason to believe otherwise.

We are not talking about Itanium, only about x86, MIPS, and x64.

Regardning AMD, the "AMD64 Architecture Programmerâÿôÿý™s Manual Volume
2: System Programming. Pub. #24593":

"Alignment Mask (AM) Bit. Bit 18. Software enables automatic alignment
checking by setting the AM bit to 1 when eFLAGS.AC=1. Alignment
checking can be disabled by clearing either AM or eFLAGS.AC to 0. When
automatic alignment checking is enabled and CPL=3, a memory reference
to an unaligned operand causes an alignment-check exception (#AC)."

Kernel mode, which is what we are talking about, runs with CPL=0,
and thus this bit has no effect in kernel mode. Furthermore,
this is not the operating mode usually used (as I qualified
earlier).

Because this is severely off-topic and, if anything, becoming
more so, I am going to make this my last post in this thread.

 

[Tor Rustad]

Ben Pfaff wrote:

[..]

We are not talking about Itanium, only about x86, MIPS, and x64.

I was talking about Itanium all along, and believe, so was Microsoft.

 

[J. J. Farrell]

Not so strange, if you consider the Windows DDK doc:

"On 32-bit Windows platforms, the operating system automatically fixes
kernel-mode memory alignment faults and makes them invisible to the
application. It does this for the calling process and any descendant
processes. This feature, which often dramatically reduces performance,
has not been implemented in 64-bit Windows. Thus, if your 32-bit driver
contains misalignment bugs, you will need to fix them when porting to
64-bit Windows."
- Microsoft, Kernel-Mode Driver Architecture: Windows DDK

IIRC, regarding MIPS, I have already given reference to the MSDN doc
elsewhere in this thread. <g>

The term "64-bit Windows" in such docs usually refers to Windows for the
Itanium Processor Family.