new standard for malloc() suggested

[Karl Heuer]

In article <1790 at batcomputer.tn.cornell.edu> braner at batcomputer.UUCP (braner) writes:
>I've been bitten by this, and would like to see a bigmalloc() with
>a LONG argument!  (Can't change malloc itself, that'll break current
>programs...).

As of the May86 Draft Proposal, ANSI was declaring the argument of malloc() to
be "size_t", which is the unsigned arithmetic type of the appropriate width.
As you suggest, this may break current programs (on machines with 16-bit ints
and 32-bit pointers), but probably not many, since most args to malloc() are
multiplied by sizeof(something), and sizeof() also returns a size_t.

Btw, "lmalloc()" is a more likely name.  (Cf. "lseek()" from earlier "seek()")

>PS: to iterate an earlier suggestion: let's REQUIRE that char, short,
>int and long have a MINIMUM size of 8, 8, 16 and 32 bits respectively,
>and perhaps that 'long' be large enough to hold a pointer to any type
>(or at least the difference between two pointers whenever that difference
>is meaningful) (only need 16 bits for THAT on an Intel chip :-)

8 bits isn't enough for short int; ANSI is mandating 16.  (There's "signed
char" which can be used as an arithmetic type containing at least 8 bits.)
The difference between two pointers is "ptrdiff_t", which is sort of like the
signed version of size_t.  I don't know if "long int" is guaranteed to be big
enough -- it's conceivable that someone would want to implement 32-bit long
ints on a 64-bit addressible machine, and have to create a "long long int" so
he'd have something to typedef "ptrdiff_t" to.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint