hilfingr@tully.Berkeley.EDU.berkeley.edu (Paul Hilfinger) (03/04/88)
Does anyone know of widely-used programs that depend on the type `char' being signed? That is, how many programs would break if `unsigned char' and `char' were the same type? One should not depend on chars being signed, but not all programmers are reluctant to use implementation-dependent features with abandon. Thanks for your comments. Paul Hilfinger hilfingr@ginger.Berkeley.EDU
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/04/88)
In article <23209@ucbvax.BERKELEY.EDU> hilfingr@tully.Berkeley.EDU.berkeley.edu (Paul Hilfinger) writes: >Does anyone know of widely-used programs that depend on the type >`char' being signed? That is, how many programs would break if >`unsigned char' and `char' were the same type? A large number of PDP-11 UNIX programs were in this category, for example much of the GPS-based PWB/Graphics. By now, I think the version in use here has all these bugs fixed. (NOT the AT&T way, which was to use #ifdef u3b2 rather than change the code to work portably.) The most common portability error in this regard is char c; while ((c = getchar()) != EOF) ...
msb@sq.uucp (Mark Brader) (03/07/88)
> > ... That is, how many programs would break if > > `unsigned char' and `char' were the same type? Doug Gwyn notes: > The most common portability error in this regard is > char c; > while ((c = getchar()) != EOF) > ... [c should of course be int] In fact, this is a bug in any case, if the code is supposed to handle binary data. On machines where chars are signed, this loop will wrongly terminate as soon as it reads a byte containing the value (char)EOF, i.e. usually 0xFF. I have encountered programs that failed in precisely this way. Mark Brader "When a supposedly indivisible transaction SoftQuad Inc., Toronto fails to complete properly, this is known utzoo!sq!msb, msb@sq.com as an atomic bomb." -- Peter Neumann