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.