size_t

[R. Vuurboom]

In article <1003 at cbnewsl.ATT.COM> dfp at cbnewsl.ATT.COM (david.f.prosser) writes:
>In article <971 at tukki.jyu.fi> tarvaine at tukki.jyu.fi (Tapani Tarvainen) writes:
>>Something related which I would call a bug is the behaviour of
>>calloc() that e.g., calloc(1000,1000) won't give an error or NULL but
>>silently truncates the product to 16960 (== 1000000 && 0x0ffff) and
>>allocates that amount.  What does the pANS say about overflow handling
>>in this situation?
>>-- 
>
>There is a general statement in section 4.1.6 for the arguments to the
>library functions.  It allows undefined behavior in the library if a
>function is passed arguments with invalid values, or values outside of
>the function's domain.  

True but not particularly relevant (me thinks) since each argument _is_
valid and well within (I hope!) the domain that size_t can handle.

>Since calloc() must produce an object with no more bytes than can be 
>counted in a size_t, 

Care to quote the relevant sentence? Doesn't seem to have made it into my
Jan 88 draft :-).


Quoting from the Mark Williams Ansi C - A lexical guide:

calloc allocates a portion of memory large enough to hold count items,
each of which is size bytes long. It then initializes every byte within
the portion to zero.

calloc returns a pointer to the portion allocated. The pointer is aligned for
any type of object. If it cannot allocate the amount of memory requested,
it returns NULL.

My guess is that the above implementation is broken.

In the above case, if you're using calloc to allocate memory for an array then
you can't use sizeof to find the size of your array (in bytes) since sizeof 
returns size_t. Could this be the source of confusion?

>Dave Prosser	...not an official X3J11 answer...

Roelof Vuurboom ...still not an official X3J11 answer...
-- 
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof at idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof