Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.std.c
Subject: Re: size_t
Keywords: calloc, size_t
Message-ID: <163@ssp1.idca.tds.philips.nl>
Date: 12 Jul 89 18:33:23 GMT
References: <934@tukki.jyu.fi> <845@cbnewsl.ATT.COM> <941@tukki.jyu.fi> <975@cbnewsl.ATT.COM> <971@tukki.jyu.fi> <1003@cbnewsl.ATT.COM> <149@ssp1.idca.tds.philips.nl> <1062@cbnewsl.ATT.COM>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 24

In article <1062@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
>In article <149@ssp1.idca.tds.philips.nl> roelof@idca.tds.PHILIPS.nl (R. Vuurboom) writes:
> [Interesting and intricate argument why calloc(1000,1000) could even
>  dump its core on the floor]

phew!

>calloc(1000,1000) occurs.  Moreover, as the argument hinges on the less than
>strictly conforming nature of the call, and since everything except the
>result of the multiplication is strictly conforming, the argument may well
>be tenuous.  I, nevertheless, am sticking by my guns.

Well...as long as you don't shoot yourself in the foot :-)

I think your train of argument is (formally) correct.
I agree with Doug Gwyn however that allowing the calloc to fail to ensure
that a _possible_ sizeof call will succeed seems to be putting the cart
before the horse. It makes more sense to me to just define nonconformant
behaviour for sizeof for objects larger than size_t can handle.

>
>Dave Prosser	...not an official X3J11 answer... (of course)

Of course :-)