From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.user Subject: deprecated symbol warnings Date: Fri, 13 May 2005 22:52:22 -0400 Message-ID: <5255fb95816d4cfc841223643e3481a8@raeburn.org> References: <41DEC762.765FDC9F@veritas.com> <41DED481.AEF0CABB@veritas.com> <170174E4-6347-11D9-9F67-000A95909EE2@raeburn.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1116039547 30379 80.91.229.2 (14 May 2005 02:59:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 May 2005 02:59:07 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat May 14 04:59:04 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DWmri-0005zb-5F for guile-user@m.gmane.org; Sat, 14 May 2005 04:58:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DWmtF-0000En-Kl for guile-user@m.gmane.org; Fri, 13 May 2005 23:00:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DWmqc-0006CU-MH for guile-user@gnu.org; Fri, 13 May 2005 22:57:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DWmpm-0005Bi-5a for guile-user@gnu.org; Fri, 13 May 2005 22:56:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DWmp2-0003pG-Nt for guile-user@gnu.org; Fri, 13 May 2005 22:56:12 -0400 Original-Received: from [207.172.4.63] (helo=smtp04.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DWmuW-0006E9-5z for guile-user@gnu.org; Fri, 13 May 2005 23:01:52 -0400 Original-Received: from 65-78-24-4.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO raeburn.org) (65.78.24.4) by smtp04.mrf.mail.rcn.net with ESMTP; 13 May 2005 22:53:32 -0400 X-IronPort-AV: i="3.93,108,1115006400"; d="scan'208"; a="34552544:sNHT29264270" Original-Received: from [18.18.1.76] (KEN-WIRELESS.MIT.EDU [18.18.1.76]) by raeburn.org (8.12.11/8.12.11) with ESMTP id j4E2qN1h008362 for ; Fri, 13 May 2005 22:52:29 -0400 (EDT) In-Reply-To: <170174E4-6347-11D9-9F67-000A95909EE2@raeburn.org> Original-To: guile-user@gnu.org X-Mailer: Apple Mail (2.622) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4491 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4491 Some time back, I wrote: > It might be a bit annoying to do in the source, but what about > flagging deprecated symbols while still allowing their use, in the > non-"--disable-deprecated" case? > > E.g., declare a function SCM_LENGTH, which is declared in the header > file with a macro which under recent enough versions of GCC expands to > __attribute__((deprecated)) and [blah blah blah] and kind of volunteered myself to implement it. Well, I've got a rough version up and limping, that does both compile-time and link-time warnings: % make depr gcc -I/var/raeburn/guile/guile-afs/Install/include -g -c -o depr.o depr.c depr.c: In function `main': depr.c:6: warning: `SCM_ICDR' is deprecated (declared at /var/raeburn/guile/guile-afs/Install/include/libguile/deprecated.h:54) 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.) 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: #if defined(SCM_DISABLE_DEPRECATION_WARNINGS) # define SCM_DECL_DEPRECATED /* empty */ #elif __GNUC__ >= 3 # define SCM_DECL_DEPRECATED __attribute__((deprecated)) #elif defined _WIN32 /* TBD: How many old versions of the compiler support this? Will older ones complain, or ignore it? */ # define SCM_DECL_DEPRECATED __declspec(deprecated) /* UNTESTED */ #else # define SCM_DECL_DEPRECATED /* empty, no compile-time warnings */ #endif /* 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. */ /* From eval.h: Macros for handling ilocs. These were deprecated in guile * 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 and in the source files: #undef SCM_IFRINC SCM_DEPRECATED (SCM_IFRINC); scm_t_bits SCM_IFRINC = (0x00000100L); #undef SCM_ICDR SCM_DEPRECATED (SCM_ICDR); scm_t_bits SCM_ICDR = (0x00080000L); #undef SCM_IFRAME SCM_DEPRECATED (SCM_IFRAME); long SCM_IFRAME(SCM n) { return ((long)((SCM_ICDR-SCM_IFRINC)>>8) & (SCM_UNPACK (n) >> 8)); } The link-time warnings are a bit messier. So far, I'm working with a macro SCM_DEPRECATED(SYMBOLNAME) that gets used at the top level (outside of any functions), and on systems that support it -- that configure test isn't written yet, so basically it's x86-linux configurations -- it spits out a string into section .gnu.warning.SYMBOLNAME that the GNU linker will use if SYMBOLNAME is referenced. It's a const char array with a synthesized name based on the symbol name, so if the symbol in question is a function, it'll be easy for the function to use that symbol in a call to scm_c_issue_deprecation_warning (though I don't know if I need to worry about i18n interactions there). I'm actually working on a couple different forms, one which always causes the message to be available to the code, and one which only outputs the message if separate sections are supported; the latter would be for the case where the code doesn't explicitly use the message, and we'd be wasting space on a platform that doesn't support warning sections. There's also another form of the macro which allows the message to be specified separately, so the programmer can be told which other functions should be used instead. (I'm in the process of reworking some of these macros, so I don't have a good code sample right now.) On Windows, actually, I'm told there are pragmas which can produce deprecation warnings for uses of macros, without having to mess around with turning them into variables. But this scheme I'm using above ought to work on both GNU and Windows compilers, and is less messy than trying to handle each separately. (Note that I haven't tested the Windows version yet.) Comments, before I take this too much further? Ken _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user