Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!rpi!bu.edu!m2c!umvlsi!umaecs!gerst From: gerst@ecs.umass.edu Newsgroups: comp.lang.c Subject: Re: What breaks? (was Re: 64 bit longs?) Message-ID: <12106.27970639@ecs.umass.edu> Date: 18 Jan 91 14:29:13 GMT Lines: 57 Reply-To: lloyd@ucs.umass.edu >Subject: Re: What breaks? (was Re: 64 bit longs?) >From: adeboer@gjetor.geac.COM (Anthony DeBoer) > >In article <1991Jan15.053356.2631@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >>In article <54379@eerie.acsu.Buffalo.EDU> chu@acsu.buffalo.edu (john c chu) writes: >>>>It is intuitively appealing, but I would be surprised to see anyone >>>>implementing it: it would break far too much badly-written software. >>> >>>Can someone please tell me what would break under that model and why? >> >>There is an awful lot of crufty, amateurish code -- notably the Berkeley >>kernel networking stuff, but it's not alone -- which has truly pervasive >>assumptions that int, long, and pointers are all the same size: 32 bits. >> >>At least one manufacturer of 64-bit machines has 32-bit longs and 64-bit >>long longs for exactly this reason. >> >>The problem can largely be avoided if you define symbolic names for your >>important types (say, for example, net32_t for a 32-bit number in a TCP/IP >>header) and consistently use those types, with care taken when converting >>between them, moving them in and out from external storage, and passing >>them as parameters. This is a nuisance. It's a lot easier to just treat >>all your major types as interchangeable, but God will get you for it. > >It seems to me that there really isn't any _portable_ way to declare a 32-bit >long, for example. Not that I would want to advocate changing the syntax of C >[again], but for most software the key thing is that the integer has at least >enough bits, rather than a precise number of them, so perhaps if there was >some declaration sequence like "int[n] variable", where n was the minimum >number of bits needed, and the compiler substituted the appropriate integer >size that met the requirement (so an int[10] declaration would get 16-bit >integers, for example), then the language might take a step toward >portability. A bitsizeof() operator that told you how many bits you actually >had to play with might help too, but even then you'd have to allow for >machines that didn't use two's complement representation. gack-o-matic! PL/1! run away! run away! :) IMHO, the ideal language would have two forms of scalar values; 1) ranges (min..max) 2) bitfields on an non-struct basis. This would solve sooooooooooooooo many headaches. Of course C has neither of these, thus giving me serious migraines :) [ stuff deleted ] >-- >Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com >Programmer, Geac J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer >Toronto, Ontario, Canada #include Chris Lloyd - lloyd@ucs.umass.edu "The more languages I learn, the more I dislike them all" - me