Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!jarthur!nntp-server.caltech.edu!coil!manning From: manning@coil.caltech.edu (Evan Marshall Manning) Newsgroups: comp.lang.c Subject: Re: Turbo C large character array Message-ID: Date: 6 Aug 90 16:14:05 GMT References: <14260@shlump.nac.dec.com> Sender: news@laguna.ccsf.caltech.edu Distribution: comp Organization: California Institute of Technology Lines: 24 farrell@onedge.enet.dec.com (Bernard Farrell) writes: >In article <17ac63d1.ARN02634@xenon.stgt.sub.org>, alf@xenon.stgt.sub.org (Ingo Feulner) writes... >> >>But doesn't say the ANSI standard that malloc() mustn't allocate more than >>64K once a time? (so says my Lattice C manual) >'Fraid not. While 64K might be a reasonable restriction on older PC systems, >it would kill me on VAXen, etc. Section 4.10.3 of The Standard has no mention >of Implementation Limits. I believe malloc() takes size_t = unsigned int. On systems where int is 16 bits 64K is indeed the limit. On some DOS systems i believe you can set int size to 32 bits with a compiler switch, but I'm not sure if malloc() is smart enough to take advantage. -- Evan *************************************************************************** Your eyes are weary from staring at the CRT for so | Evan M. Manning long. You feel sleepy. Notice how restful it is | is to watch the cursor blink. Close your eyes. The |manning@gap.cco.caltech.edu opinions stated above are yours. You cannot | manning@mars.jpl.nasa.gov imagine why you ever felt otherwise. | gleeper@tybalt.caltech.edu