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: Re: deprecated symbol warnings Date: Sat, 14 May 2005 14:48:23 -0400 Message-ID: <28ae757805033aac63a3f7bf8f4b1ccd@raeburn.org> References: <41DEC762.765FDC9F@veritas.com> <41DED481.AEF0CABB@veritas.com> <170174E4-6347-11D9-9F67-000A95909EE2@raeburn.org> <5255fb95816d4cfc841223643e3481a8@raeburn.org> <4285F1CA.5070602@ossau.uklinux.net> 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 1116097438 28317 80.91.229.2 (14 May 2005 19:03:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 May 2005 19:03:58 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat May 14 21:03:56 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DX1uq-0001gI-Ir for guile-user@m.gmane.org; Sat, 14 May 2005 21:03:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DX1wW-0001T9-9L for guile-user@m.gmane.org; Sat, 14 May 2005 15:04:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DX1ud-0000o6-1m for guile-user@gnu.org; Sat, 14 May 2005 15:02:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DX1uR-0000jZ-8b for guile-user@gnu.org; Sat, 14 May 2005 15:02:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DX1uP-0000fq-Py for guile-user@gnu.org; Sat, 14 May 2005 15:02:45 -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 1DX1of-0004B4-Lt for guile-user@gnu.org; Sat, 14 May 2005 14:56:49 -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; 14 May 2005 14:48:25 -0400 X-IronPort-AV: i="3.93,109,1115006400"; d="scan'208"; a="34707620:sNHT30713902" Original-Received: from [18.101.0.226] (laptop.raeburn.org [18.101.0.226]) by raeburn.org (8.12.11/8.12.11) with ESMTP id j4EImONH003100; Sat, 14 May 2005 14:48:24 -0400 (EDT) In-Reply-To: <4285F1CA.5070602@ossau.uklinux.net> Original-To: Neil Jerram 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:4496 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4496 On May 14, 2005, at 08:40, Neil Jerram wrote: > This looks very useful. I'm not an expert in this kind of thing, but > here are some comments. Thanks... >> #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 _WIN32 equivalent? I have no idea. I do a small amount of work with MSVC, and the other compiler I'd be concerned about would be GCC, which is checked for first (though, actually, only for gcc 3 and later, should fix that); I have no idea what other Windows compilers would do, though I would expect for maximum interoperability they would implement or at least ignore the __declspec annotations. In the code I deal with at work, we generally check _WIN32. I'm hoping some Windows developer can help out here... we've got some at work, maybe I can ping them about it. >> /* 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. *sigh* I was afraid of that. So when do we start requiring "real" ANSI C support? :-( Doing this means the compile-time messages will give the wrong symbol names. They'll be close to the names used by the application, but not the same. Still, getting messages that are close is probably better than explaining to people why this strange use of the preprocessor is actually valid and it's their compiler that's broken. I wonder if it's really a problem these days, though, a decade and a half after the spec was published.... > Nice. Slight extra overhead, but well worth it IMO for the extra > function. Yeah, consuming a bit more space in the library is slightly annoying, but the run-time performance for deprecated functions probably isn't anything to worry about. >> 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? 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... > 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. 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. 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. Turning macros into variables and/or functions is needed even without link-time warnings, as GCC can't attach attributes to the macros, only to the variable and function symbols, so it doesn't simplify things all that much. >> 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. Ken _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user