Xref: utzoo comp.lang.eiffel:331 comp.lang.c:20162
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cica!ctrsol!ginosko!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond!diamond
From: diamond@diamond.csl.sony.junet (Norman Diamond)
Newsgroups: comp.lang.eiffel,comp.lang.c
Subject: Re: Character and string literals
Message-ID: <10527@socslgw.csl.sony.JUNET>
Date: 11 Jul 89 00:57:07 GMT
References: <102@enea.se>
Sender: news@csl.sony.JUNET
Reply-To: diamond@csl.sony.junet (Norman Diamond)
Followup-To: comp.lang.eiffel
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 26

comp.lang.c has been added to the distribution of this followup.

Mr. Sommarskog tested the Eiffel compiler to see which characters are
accepted in character and/or string literals.  The Eiffel compiler
generates a portable assembly code (C of course) as intermediate code.

In article <102@enea.se> sommar@enea.se (Erland Sommarskog) writes:

>  Now, what about the error the C compiler detected? The cause is
>the very last string, which contains character 255. (Which corre-
>sponds to lowercase dotted "y" in 8859/1.) Apparently the C compiler
>takes this end of file. (My knowledge of C and Unix is little, but
>isn't -1 often a code for end of file? And -1 and 255 is the same
>thing for a byte.)

Indeed yes.  There are periodic flamefests in comp.lang.c, reminding
C programmers that they should getchar() into a short or int, instead
of into a char, so that they can test the int value correctly against
the constant EOF, which is -1.  Looks like some programmer wrote a
C compiler without knowing how to use C.  (This happens a lot.)

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
 The above opinions are claimed by your machine's init process (pid 1), after
 being disowned and orphaned.  However, if you see this at Waterloo, Stanford,
 or Anterior, then their administrators must have approved of these opinions.