Re: deprecated symbol warnings

[Ken Raeburn]

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.

Okay...

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

Ken

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.