Re: deprecated symbol warnings

[Neil Jerram]

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

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.

Regards,
        Neil