mms7r@krebs.acc.Virginia.EDU (Mitch Smith) (08/23/90)
System: RS/6000 Model 530
AIX 3.1
AIX XL C Compiler/6000
Problem:
The character constant in the following short program
produces a bogus warning.
/* test1.c */
main()
{
int c;
c = '\x';
printf("c = %c\n", c);
exit(0);
}
The output of the compiler invoked as "cc" is as follows:
$ make test1
cc -O test1.c -o test1
5 | c = '\x';
..............a..
a - 1506-235: (W) Illegal escape sequence x ignored.
$
In fact, 'x' is not ignored. When executed, the
compiled program prints "c = x".
The program above compiles without errors or warnings
on an AT&T 3B15, an SGI IRIS 3030, a MicroVAXII BSD4.3,
a MIPS M/120, an SGI IRIS 4D/310, and an IBM-PC with
Microsoft C 5.1.
According to K&R (1978), page 181, under the section on
character constants: "If the character following a
backslash is not one of those specified, the backslash is
ignored." [The "specified" escape sequences being '\n',
'\t', etc.]
Thus, the escape sequence should not be illegal, and if the
warning message is going to print anything it should be
the backslash that should be ignored. Has this behavior
been outlawed by a recent Standard?
Mitch Smith
Department of Microbiology mms7r@virginia.edu
University of Virginia ...!{uunet,mcnc}!virginia!mms7r
Charlottesville, VA 22908 (804) 924-2669ron@woan.austin.ibm.com (Ronald S. Woan) (08/23/90)
In article <1990Aug23.034343.11444@murdoch.acc.Virginia.EDU>, mms7r@krebs.acc.Virginia.EDU (Mitch Smith) writes: Mitch> Problem: The character constant in the following short program Mitch> produces a bogus warning. Mitch> /* test1.c */ main() { int c; Mitch> c = '\x'; printf("c = %c\n", c); exit(0); } Mitch> ..............a.. a - 1506-235: (W) Illegal escape sequence x Mitch> ignored. $ Mitch> In fact, 'x' is not ignored. When executed, the Mitch> compiled program prints "c = x". Mitch> According to K&R (1978), page 181, under the section on Mitch> character constants: "If the character following a Mitch> backslash is not one of those specified, the backslash is Mitch> ignored." [The "specified" escape sequences being '\n', Mitch> '\t', etc.] Yes, get the new ANSI edition of K&R. On page 193: "If the character following the \ is not one of those specified, the behavior is undefined." And actually, 'x' just happens to have been defined for specifying constants in hex, i.e. '\x07' is the bell. You should thank your lucky stars that you got the right output or the fact that IBM has tried to be as backwards compatible as possible, so they only gave you a very good warning message with an indication of what it was going to do with it. Anyway, this doesn't seem like something you should be trying to do anyway, afterall what's wrong with c='x'? Ron +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan @cs.utexas.edu:ibmchs!auschs!woan.austin.ibm.com!ron + + alternatives woan@peyote.cactus.org or woan@soda.berkeley.edu + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
guy@auspex.auspex.com (Guy Harris) (08/24/90)
> Thus, the escape sequence should not be illegal, and if the > warning message is going to print anything it should be > the backslash that should be ignored. Has this behavior > been outlawed by a recent Standard? Yes. *The* recent Standard (ANSI X3.159-1989, "C89") says that "\xNN" is an escape sequence that means "treat NN as hex digits, and stuff the character with that value into the string". See 3.1.3.4 Character Constants. (The "NN" is just an example; there's no requirement that there be exactly two or no more than two characters in the sequence.)
lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) (08/25/90)
In article <3239@awdprime.UUCP> @cs.utexas.edu:ibmchs!auschs!woan.austin.ibm.com!ron writes: >In article <1990Aug23.034343.11444@murdoch.acc.Virginia.EDU>, >mms7r@krebs.acc.Virginia.EDU (Mitch Smith) writes: >Mitch> Problem: The character constant in the following short program >Mitch> produces a bogus warning. >Mitch> /* test1.c */ main() { int c; >Mitch> c = '\x'; printf("c = %c\n", c); exit(0); } >Mitch> ..............a.. a - 1506-235: (W) Illegal escape sequence x >Mitch> ignored. $ > >Mitch> In fact, 'x' is not ignored. When executed, the >Mitch> compiled program prints "c = x". > [text deleted] > >Yes, get the new ANSI edition of K&R. On page 193: "If the character >following the \ is not one of those specified, the behavior is >undefined." And actually, 'x' just happens to have been defined for >specifying constants in hex, i.e. '\x07' is the bell. You should thank >your lucky stars that you got the right output or the fact that IBM >has tried to be as backwards compatible as possible, so they only gave >you a very good warning message with an indication of what it was >going to do with it. Anyway, this doesn't seem like something you >should be trying to do anyway, afterall what's wrong with c='x'? > Nit: I think a "very good warning message" should be more accurate, e.g.: (W) Undefined escape sequence '\x'. Replaced by 'x'. More importantly, this and an earlier posting referred to the '\xNN' escape sequence, where NN is a hex number indexing the ASCII character set. It seems to me that this should only apply to the situation where the '\x' is followed by at least one character from the set [0123456789ABCDEF]. That is, '\x' should be treated like any other undefined, non-hex escape sequence. (Note this is exactly what the compiler has done. I'm not taking issue with the compiler, but with the two postings.) If you try to interpret '\x' as a hex escape, the only reasonable (?) interpretation is '\x00' and the compiler should insert a NUL character. This is not a recommendation on my part. This probably ought to go to comp.lang.c.dementia, but I don't subscribe to that newsgroup. Ken Lindahl lindahl@violet.berkeley.edu Advanced Technology Planning, Information Systems and Technology University of California at Berkeley P.S. to Mitch: You really should have recognized the problem as soon as you saw the error number, "1506-235". :-)
ron@woan (Ronald S. Woan) (08/27/90)
In article <1990Aug24.234147.9710@agate.berkeley.edu>, lindahl@violet.berkeley.edu (Ken Lindahl 642-0866) writes: Ken> Nit: I think a "very good warning message" should be more Ken> accurate, e.g.: (W) Undefined escape sequence '\x'. Replaced by Ken> 'x'. Agreed that this would have been a better error message, but I don't think that it is doable with the NLS messages because the warning message gets taken directly from the database so it doesn't seem to me that the 'x' specifics can be easily included. Let me point out that the warning was give pointing at the '\' though it isn't excatly clear that the 'x' wouldn't be ignored, as well from the message. Perhaps '\' ignored would have been the best choice for a warning. Ken> More importantly, this and an earlier posting referred to the Ken> '\xNN' escape sequence, where NN is a hex number indexing the Ken> ASCII character set. It seems to me that this should only apply Ken> to the situation where the '\x' is followed by at least one Ken> character from the set [0123456789ABCDEF]. That is, '\x' should Ken> be treated like any other undefined, non-hex escape sequence. Ken> (Note this is exactly what the compiler has done. I'm not taking Ken> issue with the compiler, but with the two postings.) If you try Ken> to interpret '\x' as a hex escape, the only reasonable (?) Ken> interpretation is '\x00' and the compiler should insert a NUL Ken> character. This is not a recommendation on my part. Reread my quote from the book and you'll find that behavior of '\x' and other undefined sequences is undefined in the ANSI standard... Anyway, a reasonable compiler (i.e. xlc) will go back to just ignoring the '\' to keep from breaking old code. +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan woan@peyote.cactus.org or woan@soda.berkeley.edu + + other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (09/01/90)
In article <3299@d75.UUCP> woan@soda.berkeley.edu writes: >Agreed that this would have been a better error message, but I don't >think that it is doable with the NLS messages because the warning >message gets taken directly from the database so it doesn't seem to me >that the 'x' specifics can be easily included. Just to correct this: the NLS messages can contain any text, including printf() formatting sequences. The difference is that they have added positional tags to them, so if the translated message gets its phrases shifted around, the parameters are still in the right place. (So there's no excuse for not having a better message :-) ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmaus!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night