Quote without comment on char constant expansion
John Gilmore
gnu at hoptoad.uucp
Tue Apr 12 09:54:21 AEST 1988
Date: Mon, 11 Apr 88 20:18:56 +0100
From: "Chuck Clanton" <sun!sunuk!pan!aratar!chac>
Subject: did you find this one?
we found an awful gcc problem in a compiling (preprocessing actually)
a program that fooled around with ioctl settings with #defines
in <sys/ioctl.h>...the gcc version didnt work, the pcc version did.
we investigated further and simplified the problem to the following
difference in interpretation:
$ cat foo.c
#define blah(t) 't'
main()
{
printf("should this be a t or an f? %c\n", blah(f));
}
$ gcc foo.c # gnu c compiler
$ a.out
should this be a t or an f? t
$ pcc foo.c # ultrix 2.0 pcc compiler
$ a.out
should this be a t or an f? f
$ vcc foo.c # vax ultrix c compiler
$ a.out
should this be a t or an f? f
on an IBM PC-RT under AIX (system V)
$ cc foo.c
$ a.out
should this be a t or an f? f
$
on a big VAXEN under BSD 4.3
$ cc foo.c
$ a.out
should this be a t or an f? f
$
it would seem that gcc is outvoted, though i am sympathetic to
its interpretation. ritchie says "Text inside a string or a
character constant is not subject to replacement" in "The C
Programming Language" paper. k&r merely mentions the string
issue. however, the ritchie reference would appear to me to
qualify what triggers the macro expansion, not what the macro
expansion does once triggered. so the language hair-splitters
can argue about this for a long time, but the language users have
a problem right now. i am not sure where ansi sits on this one.
vcc and gcc both claim to be ansi compatible.
did you find this one in your compile of all of the berkeley
software distribution? if not, tell me where it should be
reported and i will send it in.
Date: Mon, 11 Apr 88 23:33:19 +0100
From: "Chuck Clanton" <sun!sunuk!pan!aratar!chac>
Subject: gcc is surely wrong
well, i just came upon this further piece of information
that in fact it is perfectly permissible to expand inside
strings as well as character constants INSIDE the macro.
ritchie's comment is undoubtedly meant ONLY with regard
to what triggers the macro expansion.
this is from the system 5 assert.h:
#define assert(EX) if (EX) ; else _assert("EX", __FILE__, __LINE__)
EX is the expression being validated by the assert. the effect
of "EX" in the _assert call is to print out the expression itself
that has failed the assertion!
so, i suspect gcc is quite wrong.
--
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu gnu at toad.com
I forsee a day when there are two kinds of C compilers: standard ones and
useful ones ... just like Pascal and Fortran. Are we making progress yet?
-- ASC:GUTHERY%slb-test.csnet
More information about the Comp.lang.c
mailing list