Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!ucsd!helios.ee.lbl.gov!pasteur!agate!darkstar!ucscb.UCSC.EDU!funkstr From: funkstr@ucscb.UCSC.EDU (Larry Hastings) Newsgroups: comp.lang.c Subject: Re: Turbo C large character array Message-ID: <5801@darkstar.ucsc.edu> Date: 7 Aug 90 02:03:03 GMT References: <1990Jul27.193520.4689@ux1.cso.uiuc.edu> <17ac63d1.ARN02634@xenon.stgt.sub.org> Sender: usenet@darkstar.ucsc.edu Distribution: comp Organization: Knowledge Dynamics Corporation Lines: 29 X-Local-Date: 6 Aug 90 19:03:03 PDT +-In article <17ac63d1.ARN02634@xenon.stgt.sub.org>, alf@xenon.stgt.sub.org (Ingo Feulner) wrote:- +---------- | | But doesn't say the ANSI standard that malloc() mustn't allocate more than | 64K once a time? (so says my Lattice C manual) | +---------- No, not really. It's a limitation of the Intel processor's segmented architecture that you (and I) spend our days cursing -- the 64k segment size makes it stupefyingly difficult to access more than 64k at one time. (Some DOS compilers support "halloc", or "huge alloc" calls, which break this 64k barrier with a huge code overhead.) More powerful systems with flat address spaces allow allocations of megabytes at a time, and I would theorize that there are mainframe programs which allocate _gigabytes_ at times. If you have any more questions about the ANSI standard, you should buy a reference on ANSI C. The draft itself is available, as are many good (and cheaper) reference books. I don't mean to be offensive, but the _worldwide_ Usenet is really not the place to ask questions so easily answered by a good reference book. -- larry hastings, the galactic funkster, funkstr@ucscb.ucsc.edu I don't speak for Knowledge Dynamics or UC Santa Cruz, nor do they speak for me "Cocaine is God's way of telling you you're making too damn much money" --Robin Williams