** help...

[Christopher R Volpe]

In article <1912 at islay.tcom.stc.co.uk>, rmj at tcom.stc.co.uk (Rhodri
James) writes:
|>In article <11245 at crdgw1.crd.ge.com> volpe at underdog.crd.ge.com
(Christopher R Volpe) writes:
|>>First, malloc doesn't know or care (and couldn't find out if it wanted
|>>to) whether the argument being passed in is a constant expression
|>>(like sizeof(anything)) or an expression computed at runtime via
|>>a multiplication. My copy of K&R II says (section 7.8.5) that the
|>>pointer returned by malloc or calloc has proper alignment for the
|>>object in question. My manpage (SunOS 4.0.?) says that calloc USES
|>>malloc to allocate the storage, and then initializes it to zeros.
|>
|>Yes, K&R 2 says the *pointer* has proper alignment for the object in
|>question, by taking the most restrictive possibility, and I wouldn't be
|>surprised if calloc were implemented by using malloc. However, note the
|>emphasis and read on...
|>
|>>[...] the value produced [by sizeof(int *[xL]) if it were legal]
would be the
|>>same as (xL * sizeof(int *)), so malloc wouldn't know the difference.
|>
|>This is not guarenteed true for all types by anything I can find in K&R 2.

You can find it in K&R2 in sec. 6.3 (page 135 in my copy). It says, 
"The size of the array is the size of one entry times the number
of entries, so the number of entries is just 
     sizeof(keytab)/sizeof(struct key)
...
Another way to write this is to divide the array size by the size of
a specific element...
     sizeof(keytab)/sizeof(keytab[0]) "


|>The crux of the potential health hazard comes with the definition of
|>sizeof, which K&R2 says (section 6.3) gives a size_t result equal to the
|>size of the specified object or type in bytes. Nothing here guarentees
|>that the *end* of the object will be such that another object straight
|>after it in memory (which is what the multiplication implies) will be
|>correctly aligned. Many structs would give appropriately odd lengths;
|>I'm sure you don't need examples.

They would have to be padded by the compiler to make the above statement
(Sec 6.3) work out correctly. 
                                               
==================
Chris Volpe
G.E. Corporate R&D
volpecr at crd.ge.com