Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: 64 bits--why stop there?
Message-ID: <2477@crdos1.crd.ge.COM>
Date: 30 Aug 90 14:25:00 GMT
References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> <631@array.UUCP> <225@csinc.UUCP> <1372@svin02.info.win.tue.nl> <141569@sun.Eng.Sun.COM>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 26

In article <141569@sun.Eng.Sun.COM> lm@sun.UUCP (Larry McVoy) writes:

| (1)  Unix has reached the age where it has what can be called dusty deck code.
|      And this code frequently does stuff like
| 
| 	 char *bar = (char*)malloc(100);
|     
|     which doesn't work under Rob's machine.  Do we want to support this code?

  This should work under an ANSI compliant C implementation, what's the
problem. malloc() takes an arguments in bytes, returns a (void *)
pointer which may be cast to (char *) correctly.

  Neither malloc() or (void *) work in "smallest addressable unit"
increments, and a byte may be anything as long as (a) it's at least
eight bits, and (b) every printable character in the native character
set fits in a char as a positive value (char may be unsiged by default
to allow this).

  You are correct that there is old code around, but not as much as you
would think, since a lot of it has been through compilers which will
catch stuff which is not portable, or through the great portability
testing software SCO calls xenix/286 (no smiley).
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
    VMS is a text-only adventure game. If you win you can use unix.