From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: There is no returning Date: Thu, 14 Nov 2013 18:43:58 -0500 Message-ID: <87k3gaa6rl.fsf@netris.org> References: <527A836E.4050100@gnu.org> <527FDEFE.2070503@gnu.org> <527FEF6D.3010402@cs.ucla.edu> <527FEBA0.7000303@gnu.org> <87vbzva090.fsf@netris.org> <52850CE5.6090900@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384472693 10144 80.91.229.3 (14 Nov 2013 23:44:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Nov 2013 23:44:53 +0000 (UTC) Cc: Harlan Stenn , Paul Eggert , guile-devel@gnu.org, Andreas Metzler To: Bruce Korb Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 15 00:44:55 2013 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vh6al-00075k-IF for guile-devel@m.gmane.org; Fri, 15 Nov 2013 00:44:55 +0100 Original-Received: from localhost ([::1]:57797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh6ak-0002hT-Na for guile-devel@m.gmane.org; Thu, 14 Nov 2013 18:44:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh6aa-0002hF-10 for guile-devel@gnu.org; Thu, 14 Nov 2013 18:44:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vh6aU-0007aE-6D for guile-devel@gnu.org; Thu, 14 Nov 2013 18:44:43 -0500 Original-Received: from world.peace.net ([96.39.62.75]:45082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh6aU-0007a5-1b; Thu, 14 Nov 2013 18:44:38 -0500 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Vh6aM-0003GX-Jy; Thu, 14 Nov 2013 18:44:30 -0500 In-Reply-To: <52850CE5.6090900@gnu.org> (Bruce Korb's message of "Thu, 14 Nov 2013 09:48:21 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16726 Archived-At: Bruce Korb writes: > On 11/13/13 23:52, Mark H Weaver wrote: >> FYI, I recently made precisely that change to the stable-2.0 branch, >> which will become Guile 2.0.10: >> >> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=36c40440078c005cd5e239cca487d29f6f60007d;hp=b1fe20c24ccb380420ea1ffdc7f249224072dcdc > > Thank you, Mark! Would you be willing to also do it for 1.8.x? I'm sorry, but 1.8.x is long dead. The last release was nearly 3 years ago, and almost no work has been done on it since then. In the meantime, probably on the order of hundreds of bug fixes have been applied to 2.0 and never backported to 1.8. At this point, it would be a major effort to produce a new 1.8.x release that we wouldn't be ashamed of. No one has volunteered to do that work. There are many far more important things to work on, and not enough people to do it all. Guile 2.0 was released over 2.5 years ago, and is now in all the major distros, including Debian stable, the last few Ubuntu and Fedora releases, etc. Please, let's move on. > Many "stable" distros will take _years_ to advance to 2.x, I guess you mean the enterprise distros like RHEL, CentOS, etc. Do you think many users of those distros will want to use the latest autogen release? > MY technique is to blindly replace anything after "SCM_NORETURN" > with "_Noreturn" on any line #define-ing SCM_NORETURN. Looking at C11, it appears that _Noreturn belongs before the function return type, whereas __attribute__ (__noreturn__) and SCM_NORETURN goes after the formal parameter list. So I don't see how your proposed workaround can work properly. Am I missing something? Regards, Mark