[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deprecated symbol warnings
Re: deprecated symbol warnings
Sat, 14 May 2005 13:40:42 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050420 Debian/1.7.7-2
Ken Raeburn wrote:
Well, I've got a rough version up and limping, that does both
compile-time and link-time warnings:
This looks very useful. I'm not an expert in this kind of thing, but
here are some comments.
% make depr
gcc -I/var/raeburn/guile/guile-afs/Install/include -g -c -o depr.o
depr.c: In function `main':
depr.c:6: warning: `SCM_ICDR' is deprecated (declared at
gcc -o depr depr.o -L/var/raeburn/guile/guile-afs/Install/lib -lguile
depr.o(.text+0x15): In function `main':
/var/raeburn/guile/guile-afs/test/depr.c:6: SCM_ICDR is deprecated,
please don't use it
(No warning is printed at run time.)
Yes, that makes sense.
The warnings can be disabled while building guile (only while building
deprecated.c, I hope) so that -Werror doesn't kill the build.
In the header files, here's how it's taking shape, roughly:
# define SCM_DECL_DEPRECATED /* empty */
#elif __GNUC__ >= 3
# define SCM_DECL_DEPRECATED __attribute__((deprecated))
#elif defined _WIN32
Does the __declspec syntax work for all Windows compilers? If it's
actually specific to MSVC (which is the only compiler I'm familiar
with), you should use _MSC_VER. If it's for all Windows compilers, I'm
surprised by the underscore - i.e. I'd normally use WIN32; are WIN32 and
/* TBD: How many old versions of the compiler support this?
Will older ones complain, or ignore it? */
# define SCM_DECL_DEPRECATED __declspec(deprecated) /* UNTESTED */
# define SCM_DECL_DEPRECATED /* empty, no compile-time warnings */
/* N.B.: Application code will sometimes test whether one of these
macros is defined, to figure out if the version of Guile in use
predates the creation of the macro. So at deprecation time, we
still want the macro to be visible. ANSI C says "#define foo foo"
is okay, but if we get complaints about it, try switching the
non-macro name to "foo_" or "foo_deprecated" or something; make it
a simple concatenation so that we can make the other macros
continue to be simple. */
I think we should assume in advance that we'll hit trouble with this on
some platforms. Otherwise it's just another hiccup to push people away
from trying Guile out.
/* From eval.h: Macros for handling ilocs. These were deprecated in
* 1.7.0 on 2004-04-22. */
extern SCM_DECL_DEPRECATED scm_t_bits SCM_IFRINC;
extern SCM_DECL_DEPRECATED scm_t_bits SCM_ICDR;
#define SCM_IFRINC SCM_IFRINC
#define SCM_ICDR SCM_ICDR
extern SCM_DECL_DEPRECATED long SCM_IFRAME(SCM n);
#define SCM_IFRAME SCM_IFRAME
Nice. Slight extra overhead, but well worth it IMO for the extra function.
The link-time warnings are a bit messier.
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? Would link-time warnings show up when
linking against a 3rd party library that chose to use deprecated symbols?
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?)
Re: deprecated symbol warnings and Windows, Ken Raeburn, 2005/05/18
- deprecated symbol warnings, Ken Raeburn, 2005/05/13
- Re: deprecated symbol warnings,
Neil Jerram <=
- 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, 2005/05/26
- Re: deprecated symbol warnings, Ken Raeburn, 2005/05/28