Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hao!husc6!cmcl2!brl-adm!adm!edstrom%UNCAEDU.BITNET@wiscvm.wisc.EDU From: edstrom%UNCAEDU.BITNET@wiscvm.wisc.EDU Newsgroups: comp.lang.c Subject: expression types - was RE: Writing readable code Message-ID: <8184@brl-adm.ARPA> Date: Mon, 6-Jul-87 17:05:36 EDT Article-I.D.: brl-adm.8184 Posted: Mon Jul 6 17:05:36 1987 Date-Received: Tue, 7-Jul-87 06:46:33 EDT Sender: news@brl-adm.ARPA Lines: 63 In Message: <783@nu3b2.UUCP> from: "Robert C. White Jr.">In article <262@auvax.UUCP>, rwa@auvax.UUCP (Ross Alexander) writes: >} #define EOF -1 >} char c; >} while ( ( c = getchar() ) != EOF ) { /* do something */ } >} .... Interestingly enough, >} the VAX 4.2bsd cc agrees with me, and produces (code to get value of >} getchar() ommited, but it's in r0): >} >} L9998: >} cvtlb r0,-1(fp) ; coercion and assignment to c as byte >} cmpl r0,$-1 ; but comparison is int to int >} jeql L36 ; break the loop iff same >} >} whilst the SUN 4.2 cc feels otherwise, and produces (getchar() value in d0): >} >} L2000001: >} movb d0,a6@(-0x1) ; assignment to c >} cmpb #-0x1,d0 ; comparison of a byte to a byte >} jeq L23 ; break loop iff same >} VMS agrees with SUN: cvtlb r0,r2 ; integer returned in r0 -> convert to char cmpb r2,#-1 ; compare bytes - EOF 'converted' to char beql sym.2 ; break if EOF > >Sir, > In my copy of K&R's "The C Programming Language" the last >line of section 2.10 titled "Assignment Operators and Expressions" >states: "The type of an assignment expression is the type of the left >oppernd" Although VMS and the SUN conform strictly to K&R and bsd does not (on this issue) I don't exactly see how it makes a difference. >The original questioner also must be questioned. K&R repeatedly and >constantly state that in the expression (c = getchar()) c must be type >int in order to preserve the EOF condidion because EOF must lie outside >the range of any and all possible characters and that any value held by >a variable of type char is a valid character. Yeah, but what can you do except test for file error after each character or have EOF defined as something impossible to squeeze into a byte? Like 257 instead of -1. That would force the programmer to re-write the code to force the expression to the int type. Would while (EOF != (c=getchar())) .... work, i.e. force the expression to the int type or would you need while ((int)(c = getchar()) != EOF) to make it work? Either case would come as a surprise to most C programmers. Since a -1 is a -1 in either a byte, a word or a long word the old style worked regardless. I admit I had never given the operations of the conversion rules in the given context any thought until the above message. I only remember having been caught once and I never understood until now what was wrong. I was using an unsigned char variable to receive the input from the keyboard and was testing if the expression was <= 0 (to break on null char or EOF) and, of course, it could never be less than zero. I had assumed that the expression would be a signed int. Will the ANSI C standard be dealing with this issue.