martin@mwtech.UUCP (Martin Weitzel) (08/08/90)
In article <14260@shlump.nac.dec.com> 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. According to the ANSI-Standard `malloc' takes an argument of type `size_t' (4.10.3.3) which an "unsigned intgral type" (4.1.5). There are no further limits mentioned and clearly one can not request that malloc works for *every* value that can specified in the limits of the type `size_t'. (Consider the case of an implementation that allows objects of more than 64 KB size and so there's only the choice to use 4 bytes for `size_t'. Surely you can't expect now that you can malloc some GB, only because that's the maximum value you can express in 4 Bytes). Of course, malloc must act "clean" ie. return 0 if too much space is requested. So it seems that the implementor of the library could impose every limit he or she likes for the maximum space that can be allocated with malloc. Driving this to the limits, here comes the smallest ever possible implementation of these functions, useless but nevertheless within the specifications of the ANSI-Standard ... at least to my reading of the `holy scripture' :-) void *calloc(size_t nmemb, size_t size) { return 0; } void free(void *ptr) {} void *malloc(size_t size) { return 0; } void *realloc(void *ptr, size_t size) { return 0; } -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83