edstrom%UNCAEDU.BITNET@wiscvm.wisc.EDU (07/07/87)
In Message: <783@nu3b2.UUCP> from: "Robert C. White Jr." <rwhite@nu3b2.uucp> >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.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/07/87)
In article <8184@brl-adm.ARPA> edstrom%UNCAEDU.BITNET@wiscvm.wisc.EDU writes: >Will the ANSI C standard be dealing with this issue. Yes.