From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: deprecated symbol warnings Date: Thu, 26 May 2005 19:58:01 +0100 Message-ID: <42961C39.7000206@ossau.uklinux.net> References: <41DEC762.765FDC9F@veritas.com> <41DED481.AEF0CABB@veritas.com> <170174E4-6347-11D9-9F67-000A95909EE2@raeburn.org> <5255fb95816d4cfc841223643e3481a8@raeburn.org> <4285F1CA.5070602@ossau.uklinux.net> <28ae757805033aac63a3f7bf8f4b1ccd@raeburn.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1117133996 14745 80.91.229.2 (26 May 2005 18:59:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 May 2005 18:59:56 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu May 26 20:59:56 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DbNZH-00077x-Iq for guile-user@m.gmane.org; Thu, 26 May 2005 20:58:56 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbNdO-0003Dn-Qe for guile-user@m.gmane.org; Thu, 26 May 2005 15:03:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DbNcF-0002Pc-JK for guile-user@gnu.org; Thu, 26 May 2005 15:01:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DbNcB-0002Mx-2g for guile-user@gnu.org; Thu, 26 May 2005 15:01:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbNcA-0002M1-HT for guile-user@gnu.org; Thu, 26 May 2005 15:01:54 -0400 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DbNZ8-0005Xh-Pd for guile-user@gnu.org; Thu, 26 May 2005 14:58:47 -0400 Original-Received: from laruns (host81-130-111-97.in-addr.btopenworld.com [81.130.111.97]) by mail3.uklinux.net (Postfix) with ESMTP id 96D02409FCC; Thu, 26 May 2005 18:58:03 +0000 (UTC) Original-Received: from [127.0.0.1] (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 927426F784; Thu, 26 May 2005 19:58:01 +0100 (BST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en Original-To: Ken Raeburn In-Reply-To: <28ae757805033aac63a3f7bf8f4b1ccd@raeburn.org> 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:4596 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4596 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 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user