Re: deprecated symbol warnings

[Neil Jerram]

John W. Eaton wrote:
> On 14-May-2005, Ken Raeburn wrote:
>
> | > I think we should assume in advance that we'll hit trouble with this 
> | > on some platforms.  Otherwise it's just another hiccup to push people 
> | > away from trying Guile out.
> | 
> | *sigh*  I was afraid of that.  So when do we start requiring "real" 
> | ANSI C support? :-(
>
> Can you point to a widely used compiler that will actually have
> trouble with this?  If not, then maybe it is not worth worrying about?

No I can't.  But I know that we intermittently get unexpected build 
errors reported on the mailing list for even fairly mainstream OSs such 
as Solaris and HP-UX, and recently OS X, so I was just advising caution 
in order to avoid introducing a possible roadhump for people off the 
GNU/Linux/gcc mainline.  Also, in my own experience (which is 
reasonable) I've never seen "#define foo foo" used before, so I have no 
personal feel for how well supported it is.  (And you have to agree that 
it is an edge case, surely?)

However ... when advising as above, I hadn't realized that the reported 
names would be wrong.  Now that I realize that, I think it is worth 
using "#define foo foo" and handling any problems if they arise.  (We 
have future options, if we need them, for using configure tests to test 
support, and adding a suffix where necessary.)

> | Doing this means the compile-time messages will give the wrong symbol 
> | names.  They'll be close to the names used by the application, but not 
> | the same.  Still, getting messages that are close is probably better 
> | than explaining to people why this strange use of the preprocessor is 
> | actually valid and it's their compiler that's broken.  I wonder if it's 
> | really a problem these days, though, a decade and a half after the spec 
> | was published....
>
> Having the messages use the wrong names might cause a lot more
> confusion than having to explain to people that their compiler is
> broken.

Yes, agreed now.

        Neil