Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ccivax.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!rochester!ritcv!ccivax!rb From: rb@ccivax.UUCP (rex ballard) Newsgroups: net.lang.c Subject: Re: HARRIS FLAME Re: SHORT vs. INT Message-ID: <274@ccivax.UUCP> Date: Fri, 20-Sep-85 18:36:44 EDT Article-I.D.: ccivax.274 Posted: Fri Sep 20 18:36:44 1985 Date-Received: Wed, 25-Sep-85 12:23:27 EDT References: <1390@brl-tgr.ARPA> <2778@sun.uucp> <519@lasspvax.UUCP> Organization: CCI Telephony Systems Group, Rochester NY Lines: 40 > In article <2778@sun.uucp> guy@sun.uucp (Guy Harris) writes: > >People who use the C language should be sufficiently expert that they > >understand that "long" and "short" should not be selected in favor of "int" > > I follow you so far ... > > >only if they are of different sizes on the machine you're coding on. > > But I can't quite fiqure out what you mean here. Does it mean that is > if 'short' 'int' and 'long' are the same size then I should choose > something other than 'int'? > > >Period. If a C programmer doesn't understand that, then they have not been > >adequately trained in the C language and should not use the C language until > >they have been so trained. Even the "wizards" of C can get 'bit' in unfamiliar situations. A very good example of a case where short than "int" is when communicating binary information between two dissimilar processors. If a 68000 compiler consideres int to be 16 bits, and a 68020 compiler treats it as 32 bits, packed structures had better be very specific. There are cases for it where space (communication time, disk access time, and available storage) may be a deciding factor. Consider the option of sending time samples between two machines at 9600 baud. Perhaps it is time to considere standardizing the size of char, long, and short. At least we should have some small "guarenteed size" of unit like type "byte", which could always be 8 bits unsigned (or signed- vote on it). The Honeywell 6000 uses a 9 bit char, how would you impart packed binary information to it (where every bit is significant)? Speaking of inter-processor communications, how about a binary "packf()/unpackf()" function for the library. It can get real hairy trying to get a complex structure of long words, shorts, and chars between a VAX or PDP-11 and a 68000 in binary form. For that matter letting a 68000 and an 8088 share the same disk can do real strange things to "plot(5)" and similar binary files that write different order & length "ints". It's not always practical to store everything in text.