Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: new standard for malloc() suggested
Message-ID: <5450@brl-smoke.ARPA>
Date: Mon, 15-Dec-86 12:01:53 EST
Article-I.D.: brl-smok.5450
Posted: Mon Dec 15 12:01:53 1986
Date-Received: Wed, 17-Dec-86 18:50:22 EST
References: <311@bms-at.UUCP> <1790@batcomputer.tn.cornell.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) )
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 13

In article <1790@batcomputer.tn.cornell.edu> braner@batcomputer.UUCP (braner) writes:
>Aha, now that we've been reminded of the low ceiling for malloc()'s
>argument (an unsigned int, which on some systems is only 16 bits):

On such systems, you already have problems with sizeof.  X3J11
has defined a new typedef size_t, which is the unsigned integral
type of the result of sizeof (perhaps (unsigned long)).  Malloc()'s
argument has been defined to have type size_t, which solves the
problem.  Undoubtedly there are some implementations which didn't
face up to this issue before that now have to choose between
supporting existing application code as-is or changing sizeof and
malloc() to use the new type.  Many of those implementors are on
the X3J11 committee and have already "bought into" this decision.