braner@batcomputer.tn.cornell.edu (braner) (12/12/86)
[] 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): 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...). - Moshe Braner 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 :-)
ron@brl-sem.ARPA (Ron Natalie <ron>) (12/14/86)
In article <1790@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (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): Of course, on many of these machines you can't allocate more than 2**64 bytes of memory (at one time, or ever)... =Ron
caf@omen.UUCP (Chuck Forsberg WA7KGX) (12/14/86)
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):
:
: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...).
From the "386 Toolkit" documentation: "... malloc will fail if an attempt
is made to allocate more memory than a signed integer will hold. This is
a limitation of the 286 ..." "... Realloc cannot be used in large model
programs."
So, get your 386 Proton Pack and some REAL Software.
BTW, if anybody has a working adb386, drop me a line ...
Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf Omen Technology Inc "The High Reliability Software"
Voice: 503-621-3406 17505-V Northwest Sauvie Island Road Portland OR 97231
TeleGodzilla BBS: 621-3746 2400/1200 CIS:70007,2304 Genie:CAF Source:TCE022
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourlygwyn@brl-smoke.ARPA (Doug Gwyn ) (12/15/86)
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.
pinkas@mipos3.UUCP (Israel Pinkas) (12/15/86)
>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 :-) The last Intel chip to be able to guarantee that was the 8085. From the 8086/8088 and up, code could be compiled in the "large" memory model which required at least 20 bit to store, and could require up to 32 bits. -Israel -- ---------------------------------------------------------------------- UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas ARPA: pinkas%mipos3.intel.com@relay.cs.net CSNET: pinkas%mipos3.intel.com
karl@haddock.UUCP (Karl Heuer) (12/16/86)
In article <1790@batcomputer.tn.cornell.edu> braner@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@haddock.isc.com), The Walking Lint