[patch] mkcshadow improvements

[Phil Edwards]

> On Tue, May 16, 2000 at 11:54:09AM -0400, Phil Edwards wrote:
> > Nathan Myers <ncm@cantrip.org>:
> > > if we #undef __cplusplus 
> > 
> > Undefined behavior, as per [16.8]/3.  We can't #define it either.
>
> Since "we" are the implementor, "we" can choose to define any
> instance of undefined behavior.  And, in fact, gcc-2.96 seems to 
> permit it.  But it's academic, because it doesn't seem safe enough 
> to be useful.

I always took that section to mean that the symbol shouldn't be #define'd
in a header file, but rather internally by the compiler itself.

Until ten seconds ago, when I started writing this and realized that from
the Standard's viewpoint, there is no such thing as a header "file" and
no distinction is made between in-the-compiler and in-the-standard-lib.

So now my view is that /given the choice/, an implementation should define
it internally, rather than in a header file.


In a cousin thread:

> > I suppose this same property allows us to call this thing _C_ (reserved 
> > for implementors) instead of _C_something_that_makes_sense_to_nathan?
>
> But our right as implementors to define a global name "_C_" doesn't 
> help if it's not safe enough to use.
>
> I'll try to think of a name that is precise, safe, and innocuous.

I have to say, swamp seems pretty good to me.  _C_ is just too short to
be safe.  _C_internal_guts_ appeals to me, too.

Phil