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