Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!gatech!ncar!ames!lll-winken!uunet!mcvax!kth!draken!tut!tukki!tarvaine
From: tarvaine@tukki.jyu.fi (Tapani Tarvainen)
Newsgroups: comp.std.c
Subject: Re: size_t
Summary: TC kind of conforms; but a bug in calloc()?
Keywords: memory allocation, Intel 80x86, memory models
Message-ID: <971@tukki.jyu.fi>
Date: 8 Aug 89 18:52:59 GMT
References: <934@tukki.jyu.fi> <845@cbnewsl.ATT.COM> <941@tukki.jyu.fi> <975@cbnewsl.ATT.COM>
Reply-To: tarvaine@tukki.jyu.fi (Tapani Tarvainen)
Organization: University of Jyvaskyla, Finland
Lines: 34

In article <975@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes:
...
> size_t must be big enough
>to hold the number of bytes of any validly created object.
...
>Of course, if there is a "hugealloc()" function provided which is the
>only access to objects that are bigger than what sizeof or size_t can
>describe, this is still a conforming implementation.  If a program
>makes use of such a function, then a larger than size_t integral type
>would be necessary.

It turns out this is exactly the case with TurboC: malloc(), calloc()
and realloc() won't allocate blocks bigger than 64K.  If you need
such, you must use farmalloc(), farcalloc(), farrealloc(), which
expect the block size as a long, so TC appears to be conforming
in this respect after all.  

Unfortunately this apparently means there is no standard-conforming
way to create objects bigger than 64K in TC, or indeed using the huge
model at all in any useful way.  I do hope Borland does something to
this in a future version of TC, either change the behaviour of huge or
provide a separate ANSI-huge model where everything is long that needs
to be and pointer declarations and arithmetic work automatically OK
so that I can take a conforming program that needs big blocks and
compile it without any changes, just by setting a compiler option.

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