Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!tuvie!vmars!hp From: hp@vmars.tuwien.ac.at (Peter Holzer) Newsgroups: comp.arch Subject: Re: 64 bits--why stop there? Message-ID: <1791@tuvie> Date: 4 Sep 90 13:35:09 GMT References: <6106@vanuata.cs.glasgow.ac.uk> <2437@crdos1.crd.ge.COM> Sender: news@tuvie Lines: 33 Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: >Yes, it would break a _few_ programs. (e.g. incrementing a pointer cast to Agreed. It should break no program that is portable now. >an int or otherwise directly twiddling pointer bits) Adding a new type C >type called "bit" (or boolean or logical etc.) should be orthagonal to What should sizeof (bit) be? 0.125? Sizeof (char) is defined to be 1, and I don't think this will change in the near future. Of course size_t will stay an integral type, too ... Of course, gcc could get another switch -fbitsize, so that sizeof () gives the size of an object in bits, and if everybody starts to use it, it could make it into C2001 ... >existing correctly written C code, except for the added keyword. (void *)s >and (char *)s _can maintain the old semantics_ and old correct code need Yes, if all pointers have the same representation as bit pointers. >only be recompiled after a character substition, if necessary. I think >this would fall under your category "b". You would have to insert lots of sizeof (char) in mallocs (or use a compiler switch, see above). -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technische Universitaet Wien | as evolution | | | | | hp@vmars.tuwien.ac.at | in action! | | __/ | ...!uunet!mcsun!tuvie!vmars!hp | Tony Rand |