Weird problem with C compiler under SCO - I can't believe it!

[Steve Summit]

[This is a week-old thread from comp.unix.wizards which has
been adequately answered there, but it may be of interest to
comp.lang.c readers, particularly any who may still believe
that namespace pollution is merely a theoretical problem.]

In article <71 at promark.UUCP> mark at promark.UUCP (Mark J. DeFilippis) writes:
>The following short section of code does not compile using SCO XENIX 2.3.1
>and the 2.2.1 Development system, and I can't figure out why.
>
>1 main()
>2 {
>3 	char *cdecl;
>4 }
>
>Yields the errors:
>             error(3) : error 59 : syntax error : ';'
>
>If you change the name 'cdecl' to anything else, it compiles fine.
>(ccdecl, cdecll, work fine, so the only thing I can think of is some
>type of a conflict.  But a conflict with what???  Their are no macros,
>no external functions, no libraries, and the error it reports is a _syntax_
>error of all things, not a linkage error.
>
>Problems like this we don't need!  Who thinks of changing variable names?
>I mean, when you hit the point in your debugging that you are trying
>to change the name of a variable as a hack, (Like the name should really
>make a difference), it's a pretty desperate situation.

The problem, of course, is that in many PeeCee environments
"cdecl" is a new _keyword_, and keyword namespace pollution is
even more onerous than, say, external linkage namespace
pollution.

Mark's comments perfectly express the exasperation which is
(properly) felt by anyone faced with a misguidedly "extended"
and therefore nonstandard environment.  (No fair saying "but who
would ever name a variable 'cdecl?'."  The same problem bit me,
when I wrote a version of the ever-popular cdecl program.)

It should be noted that the PC compiler vendors are belatedly
seeing the errors of their ways, and are introducing compiler
switches to control the recognition of extended keywords,
although the default (which should be that extended keywords are
not recognized and are hence available to the programmer) is not
always correct.