[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.
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
- deprecated symbol warnings, Ken Raeburn, 2005/05/13
- Re: deprecated symbol warnings, Neil Jerram, 2005/05/14
- Re: deprecated symbol warnings, Ken Raeburn, 2005/05/14
- Re: deprecated symbol warnings, John W. Eaton, 2005/05/15
- Re: deprecated symbol warnings, Neil Jerram, 2005/05/16
- Re: deprecated symbol warnings, Ken Raeburn, 2005/05/16
- Re: deprecated symbol warnings, tomas, 2005/05/18
- Re: deprecated symbol warnings, Ludovic Courtès, 2005/05/18
- automated testing (was Re: deprecated symbol warnings), Ken Raeburn, 2005/05/18
- Re: deprecated symbol warnings,
Neil Jerram <=
- Re: deprecated symbol warnings, Ken Raeburn, 2005/05/28
Re: deprecated symbol warnings and Windows, Ken Raeburn, 2005/05/18