[Top][All Lists]

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

Re: deprecated symbol warnings

From: Neil Jerram
Subject: Re: deprecated symbol warnings
Date: Thu, 26 May 2005 19:58:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Ken Raeburn wrote:
On May 14, 2005, at 08:40, Neil Jerram wrote:

What is the extra benefit of link-time warnings over compile-time? Are there any cases where the user will see a link-time warning without a corresponding compile-time one?

If the application refers to Guile functions without including libguile.h, yes.

Or if an older version of gcc is used that can generate ELF sections but doesn't support the "deprecated" attribute. (I *think* "section" came first.)

Or if we add support for another compiler that lets us use 'asm' to emit warning sections or symbols or whatever the tool chain supports, but doesn't have a compile-time equivalent to the "deprecated" attribute, but we could treat that case separately.


All of which strike me as pretty marginal.

Would link-time warnings show up when linking against a 3rd party library that chose to use deprecated symbols?

Yes. Hmm, at least for a static library. I'm not sure about a shared library, if it would happen when the library was built, or used, or both. I would assume they would be printed when the library is built, at least. I'm guessing that this would probably be the most interesting of the cases.

Interesting in a sense, yes - but I was thinking that this is a good argument for NOT implementing link-time warnings. The point being that in this case the developer can't do anything about the warnings, so they're just an annoyance.

Or, in the real world, if all the non-fatal compile-time warnings have all scrolled off the screen and the trailing bits of the "make" output still visible, and the only bits likely to get looked at unless something breaks, include only the final link step.

Seriously? (In my real world, if people are concerned about warnings they put processes in place so as not to miss them.)

If it's not that interesting after all, I could drop it (as I indicated, it's the more complicated approach, though not terribly so) and just go with the compile-time warnings based on the predefined macros.

That would be my inclination.

scm_c_issue_deprecation_warning (though I don't know if I need to worry about i18n interactions there).

I don't believe it's yet been suggested that we would translate the Scheme names of primitives, so I doubt there would be a problem here. (Out of interest, do any other scripting languages do this?)

I was thinking of the "is deprecated, please use" part. The symbol names we should display as they are, but possibly the recommendation to change the application code should be given in Swahili or Klingon or whatever. That we could do at run time, and gcc could do it at compile time, but I don't think we can do anything about it at link time.

I see - thanks for explaining.


reply via email to

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