guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: deprecated symbol warnings


From: John W. Eaton
Subject: Re: deprecated symbol warnings
Date: Sat, 14 May 2005 23:17:04 -0400

On 14-May-2005, Ken Raeburn wrote:

| >> /* N.B.: Application code will sometimes test whether one of these
| >>     macros is defined, to figure out if the version of Guile in use
| >>     predates the creation of the macro.  So at deprecation time, we
| >>     still want the macro to be visible.  ANSI C says "#define foo foo"
| >>     is okay, but if we get complaints about it, try switching the
| >>     non-macro name to "foo_" or "foo_deprecated" or something; make it
| >>     a simple concatenation so that we can make the other macros
| >>     continue to be simple.  */
| >
| > 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?

| 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.

jwe

-- 
jwe at octave dot org | Peace would shock and awe me.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]