[comp.lang.c] Weird problem with C compiler under SCO - I can't believe it!

scs@hstbme.mit.edu (Steve Summit) (09/24/89)

[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@promark.UUCP> mark@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.

rhg@cpsolv.UUCP (Richard H. Gumpertz) (09/25/89)

Speaking of switches to disable non-standard extensions: I encountered a funny
problem using DEC's VAX/VMS compiler: when I tried to compile with extensions
disabled it complained about the extensions that were used in implementing the
standard .h files!

Interesting dilemma: the (hidden from the programmer) implementation of certain
ANSI-standard macros must include DEC-specific extensions.  Hence, programs
that use the standard headers and functions cannot be compiled with the
standard-only switch!

I suppose a pragma that would temporarily allow extensions could be included
in appropriate parts of the header files.  Moby sigh.

		Richard H. Gumpertz
-- 
==========================================================================
| Richard H. Gumpertz:                        ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohwak Lane, Leawood, Kansas 66206-1749 |
==========================================================================

russ@bbx.UUCP (Russ Kepler) (09/26/89)

In article <14561@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>In article <71@promark.UUCP> mark@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 : ';'
>>
>>[ rest deleted for brevity, turn out cdecl is a *keyword*]
>
>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.)
>

But this isn't the worst; I couldn't port to a major European
hardware platform because they decided that 'near' and 'far' 
weren't only keywords but that keywords that weren't yet 
implemented couldn't be redefined... can you say catch-22?  
After changing only 2500 lines of code (lets see now, sed(1),
uh-huh, '-f', yep, 'for i in *.[ch]', there we go) the code
will now compile.

Then the *real* trouble starts.  Lots of code in lots of 
libraries don't hide the entry points.  'movblk' seems rather
more popular than it used to be, 'send' is great when you 
start including the socket libs (and using 'em).

When I'm faced with one of the 'it's got to work!' situations
I start looking for common named routines/variables in my code
*and* the libs that are being included.  A quick 'nm *.a | grep 
-v ...' to a comm and I can find the duplicate.  A quick 
#define in the highest #include, a recompile and we're back in
business... after a few hours of ranting, raving, etc.

I wish that somewhere in /lib there was a file of all entry
points in all of the libs - and a standard way of comparing 
with your code's entry points.  Any pointers out there?

-- 
Russ Kepler -  Basis International
SNAILMAIL:  5901 Jefferson NE, Albuquerque, NM 87109
UUCP:       {backboneishsite}!unmvax!bbx!russ
PHONE:      505-345-5232

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/27/89)

Another thing which was left out of the ANSI standard is some name space
reserved to the user. That is, some subset of names which they promise
not to snatch away in the next standard. The space is getting pretty
thin now, with a lot of common user names being used in libraries and
stuff, and some user space would be a good thing for consideration in
the next standard.

SCO added another name to their curses library (I believe it was quit)
which conflicts with several programs I use. To top it all off the
routine is not in SysV or BSD or even SCO documentation, just an
internal name which someone forgot to make static.

-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

scott@bbxsda.UUCP (Scott Amspoker) (09/27/89)

In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>Another thing which was left out of the ANSI standard is some name space
>reserved to the user. That is, some subset of names which they promise
>not to snatch away in the next standard. The space is getting pretty
>thin now, with a lot of common user names being used in libraries and
>stuff, and some user space would be a good thing for consideration in
>the next standard.

It's becoming more and more a problem.  It has happened to us much
more lately (the past year) than ever before.  Our well thought out,
descriptive symbol names are starting to show up in system libraries
and header files.  We have no choice but to do a quick search-and-replace
to get the port finished.

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232

henry@utzoo.uucp (Henry Spencer) (09/28/89)

In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>Another thing which was left out of the ANSI standard is some name space
>reserved to the user. That is, some subset of names which they promise
>not to snatch away in the next standard...

Section 4.1.2.1 lists several classes of identifiers that are reserved, and
then flatly states:  "No other identifiers are reserved."  That is, ALL
other identifiers are explicitly promised to be available to the user.
Note also 1.7:  "A conformation implementation may have extensions
(including additional library functions) provided they do not alter the
behavior of any strictly conforming program...", with a footnote:  "This
implies that a conforming implementation reserves no identifiers other
than those explicitly reserved in this Standard."

The classes of reserved identifiers are admittedly annoyingly large, but
the promise to reserve nothing else is of considerable importance.

If by "the next standard" you mean a revised C standard, either the
revision will be upward-compatible or not.  If so, it has to preserve
these promises.  If not, then asking today's standard to make promises
on its behalf is silly.
-- 
"Where is D.D. Harriman now,   |     Henry Spencer at U of Toronto Zoology
when we really *need* him?"    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

tneff@bfmny0.UU.NET (Tom Neff) (09/28/89)

In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>Another thing which was left out of the ANSI standard is some name space
>reserved to the user. That is, some subset of names which they promise
>not to snatch away in the next standard. 

I suggest beginning all identifiers with the prefix

	leprosy_scab_

as it is unlikely that any ANSI committee would dare to approve any
new identifiers within this namespace!
-- 
I'm a Leo.  Leos don't believe    *  *  *     Tom Neff
    in this astrology stuff.        *  *  *   tneff@bfmny0.UU.NET

gwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)

In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>Another thing which was left out of the ANSI standard is some name space
>reserved to the user.

As you state it, it's simply not true.  ALL identifiers not specifically
flagged as "reserved" (for the implementation) by the Standard are
reserved for the (application) program's use.  We staked out whole
categories of name space such as is*() for use in future C standards.

It is of course up to future C standardization committees to decide
whether or not to turn "foo" into a keyword.  You can expect that they
will have to think even harder than X3J11 about compatibility problems
caused by glomming onto previously program-available name space.

The other problem you mention, of vendor-supplied libraries clashing
with application (or other libraries) use of identifiers, is a real one.
An approach like Xlib's (where all its identifiers start with a special
reserved pattern "X") is viable, absent support for genuine "classes"
or "packages".  I would however recommend that more than one character
be used for the package-specific prefix.  We use two (Xx format) for our
internal multiple-package projects, but it may take more to deal with a
large raft of vendors.

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/28/89)

In article <11157@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
|  In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
|  >Another thing which was left out of the ANSI standard is some name space
|  >reserved to the user.
|  
|  As you state it, it's simply not true.  ALL identifiers not specifically
|  flagged as "reserved" (for the implementation) by the Standard are
|  reserved for the (application) program's use.  We staked out whole
|  categories of name space such as is*() for use in future C standards.

  I see this as the diference between "you can use anything we haven't
taken" and "we will never take this." What is not in the standard is any
statement like "no future standard library calls will have external
names which begin with three alphabetic characters and an underscore. In
other words, I was not given a set of names which I can call my own and
be assurred will not conflict in the future.

|  The other problem you mention, of vendor-supplied libraries clashing
|  with application (or other libraries) use of identifiers, is a real one.

  On my schedule of things to look at next year is a program which will
take an object file and rename global symbols. I know this will break
the documentation of the vendor library, but I feel the benefits are
worth it. Obviously I would have to rename the references, too.
Naturally if I write such a thing I will post it.

-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/28/89)

In article <1989Sep27.170304.2158@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
|  In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
|  >Another thing which was left out of the ANSI standard is some name space
|  >reserved to the user. That is, some subset of names which they promise
|  >not to snatch away in the next standard...
|
|	[ discussion of names which are reserved ]
|  
|  The classes of reserved identifiers are admittedly annoyingly large, but
|  the promise to reserve nothing else is of considerable importance.

  But they *didn't* promise not to, they said they haven't yet. The
feature I mentioned as missing was a statement that not future reserved
words will be of the form {choose one}.
|  
|  If by "the next standard" you mean a revised C standard, either the
|  revision will be upward-compatible or not.  If so, it has to preserve
|  these promises.  If not, then asking today's standard to make promises
|  on its behalf is silly.

  There are no promises for the future, only the present standard. It
would have been simple to define a namespace is intended to be used only
by applications. My example in another posting was starting with three
alpha chars and an underscore. Thus, if I want to be sure I don't have
to edit my source, I can use those names exclusively.

  I assume that future committees will be composed of thoughtful people.
I was on X3J11 for two years until my group ran out of T&L money. Now
I'm in another group and I hope that I'll be able to join the next
committee. If this future committee had any hint as to what names
applications use, they would pick others. What I suggest is that this
committee could have passed a hint on to the programmers and any future
committees about what space could be left to the application.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

henry@utzoo.uucp (Henry Spencer) (09/30/89)

In article <599@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>|  The classes of reserved identifiers are admittedly annoyingly large, but
>|  the promise to reserve nothing else is of considerable importance.
>
>  But they *didn't* promise not to, they said they haven't yet...

No, they said that no other identifiers are reserved.  Period.  Full stop.
No implementation that conforms to this standard can reserve any other
identifiers.  None.  Zero.  Not just today, *ever*.  How much more of a
promise do you want?

>  There are no promises for the future, only the present standard...

I don't understand why you think today's standard could possibly make any
sort of promise that would be binding on a future standard which you have
already assumed will be incompatible with the current one, i.e. will
break promises made in the current one.  (If it is compatible, it will
keep the current one's promise and not reserve any more names.)
-- 
"Where is D.D. Harriman now,   |     Henry Spencer at U of Toronto Zoology
when we really *need* him?"    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

bobmon@iuvax.cs.indiana.edu (RAMontante) (09/30/89)

tneff@bfmny0.UU.NET (Tom Neff) <14746@bfmny0.UU.NET> :
-
-I suggest beginning all identifiers with the prefix
-
-	leprosy_scab_

One of Henry Spencer's Ten Commandments specifies a *unique* six-letter
prefix.  You've broken that commandment.  Are you planning to raze
the Commandments along with the rest of Ontario?