Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsl!dfp
From: dfp@cbnewsl.ATT.COM (david.f.prosser)
Newsgroups: comp.std.c
Subject: Re: size_t
Keywords: memory allocation, Intel 80x86, memory models
Message-ID: <1003@cbnewsl.ATT.COM>
Date: 5 Jul 89 20:49:57 GMT
References: <934@tukki.jyu.fi> <845@cbnewsl.ATT.COM> <941@tukki.jyu.fi> <975@cbnewsl.ATT.COM> <971@tukki.jyu.fi>
Reply-To: dfp@cbnewsl.ATT.COM (david.f.prosser)
Organization: AT&T Bell Laboratories
Lines: 22

In article <971@tukki.jyu.fi> tarvaine@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?
>-- 
>Tapani Tarvainen                 BitNet:    tarvainen@finjyu
>Internet:  tarvainen@jylk.jyu.fi  -- OR --  tarvaine@tukki.jyu.fi

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.  Since calloc() must produce an object with no
more bytes than can be counted in a size_t, a pair of arguments that,
while individually are valid, cannot be multiplied and produce a result
that fits in a size_t, will result in undefined behavior for calloc().
If there were some special part of calloc()'s description that
constrained the function to handle this case, the behavior would be
otherwise.

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