[Top][All Lists]

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

Re: deprecated symbol warnings

From: Ken Raeburn
Subject: Re: deprecated symbol warnings
Date: Sat, 28 May 2005 17:55:49 -0400

On May 26, 2005, at 14:58, 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?

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.

Good point.

If these were security-related warnings, I'd suggest that they should be displayed anyways, to make the end user/developer aware that they're using software that could potentially compromise their systems. But for deprecated symbols, all one could do would be to complain at the third party supplying the library.

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

Well, I haven't looked over people's shoulders much while they build software, but enough software has warnings while building that I expect that's not the normal process for a lot of people. But if an "interesting" warning (i.e., not the pointer-assignment-changes-signedness or cast-changes-alignment or other relatively benign warnings they may be in the habit of ignoring) is still on-screen when the build finishes, maybe they'll take note.

Also, in some packages, link time is when arbitrary developer-provided warnings get displayed now, if only because compile-time support hasn't been there.

Hmm... come to think of it, though, we're increasingly working in a world where building software package X requires that you have software package Y installed, and software package Y may be built via some provided package system that routinely ignores warnings as it builds and installs some large collection of packages based on some dependency tree. That might be a case where someone hacking on package X might like to know that package Y does have some issues, and they might be able to do something about it, but they wouldn't normally go looking for problems there.

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.

Okay. Unless someone else wants the link-time warnings, I'll start backing that part out of my source tree soon. They're pretty independent, so it wouldn't be hard to put them back in later as a separate bit of work.


P.S. Apparently I've got updated assignment forms I need to file -- the FSF has already sent them to me -- and I probably need to get the current disclaimer form to my current employer. So it'll take a little while yet before the patches can go in. But I'll try and send something for review soon anyways.

reply via email to

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