home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!cbmvax!jesup
- From: jesup@cbmvax.commodore.com (Randell Jesup)
- Newsgroups: comp.arch
- Subject: Re: 32 => 64 Transition
- Message-ID: <34578@cbmvax.commodore.com>
- Date: 23 Aug 92 01:57:11 GMT
- References: <1992Aug22.001234.10390@adobe.com> <1992Aug22.002912.10884@adobe.com>
- Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
- Organization: Commodore, West Chester, PA
- Lines: 26
-
- zstern@adobe.com (Zalman Stern) writes:
- >In the DEC
- >model where int is 32 bits and long and pointers are 64 bits, size_t should
- >be typedef'ed to unsigned long. That way you can allocate and manipulate
- >arrays larger than 2^32 bytes in size. At MIPS, the counter argument to this
- >was that little code out there actually conforms to the ANSI standard and
- >people use int variables to index arrays all the time. Hence if you want to
- >compile dusty decks and have them use arrays bigger than 2^32 bytes, you
- >want int to be 64 bits...
-
- But wouldn't most dusty decks be unlikely to want (or handle) arrays
- larger than 2^32 bytes? I'm sure some do, but I would think that 90+%
- (probably 99+%) of dusty decks could care less about such large objects.
-
- I'd have to side with DEC here, I'm afraid. I think more and more
- software will comply with the standard, and most programs won't be hard to
- fix (some will, but those would also be the programs that are hard to maintain
- at all).
-
- --
- "Rev on the redline, you're on your own; seems like a lifetime, but soon it's
- gone..." Foreigner
- -
- Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
- {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup
- Disclaimer: Nothing I say is anything other than my personal opinion.
-