[patch] mkcshadow improvements

Nathan Myers ncm@cantrip.org
Tue May 16 03:04:00 GMT 2000


On Tue, May 16, 2000 at 02:05:15AM -0700, Benjamin Kosnik wrote:
> >> Also, you and Nathan should work out the _C_swamp naming convention
> >> thing. Nathan, this name seems kind of silly, perhaps you could
> >> come up with something that is a bit more meaningful?  
> 
> >How about just _C_, seeing its purpose is to enclose the C headers
> >from the host environment, or is that reserved for something else?
> 
> Yeah this seems better to me too.

There is no need to change it, and there are good reasons not to.  
"_C_" is likely to collide with a vendor-chosen name, and is vague.  
"_C_Swamp" was chosen as short, precisely descriptive, and impossible 
to confuse with anything else.  That's what we look for in a good name.

It is called a "swamp" because vendors have traditionally dumped
all kinds of random flotsam and jetsam into the global namespace, 
and the _C_Swamp namespace is there to keep it from sloshing into 
namespace std.  It's called "swamp" and not "sewer" for diplomatic 
reasons, but we need a constant reminder that it is bound to be 
full of ... er, mud.
 
> >I don't have CVS, but here's the output from "diff -r" against the
> >installed include directory (attached)

Building cvs and GNU diff is not hard, and is bound to be worth 
your while.  
 
> Hmm. Spooky. Maybe a 'diff -cp' between the following two directories:
> 
> 1) install directory with hacks
> 2) install directory without hacks
> 
> This would be appreciated.

A "diff -up" against the shadow directory contents might be a lot more
useful.  Also, please place your changed versions second in the command
line, so that it doesn't seem to show your version as the original and 
the old version changed to match.

By the way, upon inspecting the diffs, the various *iso646* headers I 
find in the existing tree are totally nonconforming.  Where did they 
come from?  They should just be empty.

Nathan Myers
ncm at cantrip dot org
 


More information about the Libstdc++ mailing list