🚀 go-pugleaf

Wil Evers (wil@ittpub.nl) writes:
> (1). Is there a rule in the C standard stating that the address of *every*  
> structure - irrespective of its contents - should satisfy some alignment  
> requirement? ...

No, there is no such rule.  The example code invokes undefined behavior.
Each type has an alignment requirement, but each structure type is a
different type with no necessary relation to any other structure type.
 
> (2). If the answer to (1) is no, then is a conforming compiler allowed to  
> assign some specific alignment requirement to a data type, just because it  
> is defined as a structure, and again irrespective of the contents of the  
> structure?

Yes, it can.  Each structure type is a different type with no necessary
relation to any other NON-structure type either.

> (3). If the answer to (2) is yes, why would a compiler want to do this?

On a word-addressed machine, the natural type of pointer -- the one which
occupies one word and probably is the same size as an int -- points to a
whole word.  A pointer to an individual byte requires additional storage,
another word or halfword, to identify which byte in the word being pointed
at is meant; and one or more additional operations are also necessary when
dereferencing it, so access via the pointer is slower.

By aligning all structs on word boundaries, the implementation can use
word-pointers rather than byte-pointers whenever pointers to structs are
required.

> For example, if I write:
> 	#include <stdio.h>
> 	struct c { char data; } carray[10];
> 	int main() { printf("%u\n", sizeof carray); return 0; }

... then on a word-addressed machine the output might very well be "40".  On
that machine, sizeof (struct c *) would probably be 4 while sizeof (char *)
would be 8, or maybe 6.

Also, some machines are byte-addressed but provide faster access to objects
on word boundaries.  Implementers might choose to place everything that they
could on word boundaries whether it was strictly necessary or not.  After
all, *you* can always go and buy more memory, right?

It also seems conceivable that an implementer might want to align all
structures *smaller than the machine's register size* on a word boundary
so that struct assignment operations could be implemented efficiently
by loading into, and storing from, a register.  I have had personal
experience with a compiler where this was *not* done and the code
I was maintaining, which assigned these little structs a lot, suffered
a measurable speed penalty.  (We ended up replacing the original struct
type, on implementations where there was an integral type of the same
size, with a union of the two, using the integral type for assignments
and the struct for member access.  [Yes, this is not strictly conforming.
I think it should be; it's safe enough in practice.])
-- 
Mark Brader   | "On a word boundary, Luke, don't just hack at it. ...
msb@sq.com    |  The bytesaber is the ceremonial weapon of the Red-Eye Knight.
SoftQuad Inc. |  It is used to trim offensive lines of code.  Handwaving won't
Toronto       |  get you anywhere.  Attune yourself with the Source."
              |                 -- Steve Tarr, Alan Hastings, and Eric Raymond

My text in this article is in the public domain.

In article <1996Mar12.175916.7256@sq.com>, Mark Brader <msb@sq.com> wrote:
:Wil Evers (wil@ittpub.nl) writes:
...
:> For example, if I write:
:> 	#include <stdio.h>
:> 	struct c { char data; } carray[10];
:> 	int main() { printf("%u\n", sizeof carray); return 0; }
:
:... then on a word-addressed machine the output might very well be "40".  On
:that machine, sizeof (struct c *) would probably be 4 while sizeof (char *)
:would be 8, or maybe 6.

Or any machine could output "Segmentation fault... Core dumped"
if size_t is not unsigned int.

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

In article: <1996Mar7.151216.1793@ittpub>  wil@ittpub.nl (Wil Evers) writes:
> (1). Is there a rule in the C standard stating that the address of *every*  
> structure - irrespective of its contents - should satisfy some alignment  
> requirement? For example, is the following guaranteed to work?
> 
> 	struct a { char data[sizeof(double)]; } ana;
> 	struct b { double data; };
> 
> 	int main()
> 	{
> 		((struct b *) &ana)->data = 42.42;
> 		return 0;
> 	}
I am fairly sure not.
 
> (2). If the answer to (1) is no, then is a conforming compiler allowed to  
> assign some specific alignment requirement to a data type, just because it  
> is defined as a structure, and again irrespective of the contents of the  
> structure? For example, if I write:
> 	
> 	#include <stdio.h>
> 
> 	struct c { char data; } carray[10];
> 
> 	int main()
> 	{
> 		printf("%u\n", sizeof carray);
> 		return 0;
> 	}
> 
> would it be legal for this program to print something other than 10?
Almost certainly YES
> (3). If the answer to (2) is yes, why would a compiler want to do this?
For example:
Because the architecture is word addressed (not byte addressed), so 
indexing the array is painful unless the structures are padded up to
machine words.  (I can think of other reasons too).

In general, ISO C does not specify ANYTHING about additional padding that a 
compiler may introduce

Martin Bonner
Pi Technology, Milton Hall, Cambridge, ENGLAND
+44 1223 441256
mbonner@pires.co.uk

In article <814065992wnr@pires.co.uk> mbonner@pires.co.uk "Martin Bonner" writes:

>In general, ISO C does not specify ANYTHING about additional padding that a 
>compiler may introduce

Except that there may be no padding before the first member of a structure.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------