From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: abandon K&R C ? Date: Tue, 30 Oct 2007 08:41:22 +0900 Message-ID: <87fxzttrod.fsf@catnip.gol.com> References: <87odfcggvl.fsf@jurta.org> <471BE5D3.3050007@gmail.com> <87y7dwq7x9.fsf@catnip.gol.com> <87odepv21n.fsf@catnip.gol.com> <87ir4wjcev.fsf@catnip.gol.com> <200710261516.l9QFGQ7C001069@oogie-boogie.ics.uci.edu> <200710261941.l9QJfcH0010503@oogie-boogie.ics.uci.edu> <200710271728.l9RHSk8B019811@oogie-boogie.ics.uci.edu> <200710281838.l9SIcipk027499@oogie-boogie.ics.uci.edu> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1193701314 2170 80.91.229.12 (29 Oct 2007 23:41:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2007 23:41:54 +0000 (UTC) Cc: dann@ics.uci.edu, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 30 00:41:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ImeF1-0000qS-Ih for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2007 00:41:55 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImeEs-0000r1-2D for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2007 19:41:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ImeEp-0000q6-Bj for emacs-devel@gnu.org; Mon, 29 Oct 2007 19:41:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ImeEn-0000pi-My for emacs-devel@gnu.org; Mon, 29 Oct 2007 19:41:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImeEn-0000pf-Gu for emacs-devel@gnu.org; Mon, 29 Oct 2007 19:41:41 -0400 Original-Received: from smtp02.dentaku.gol.com ([203.216.5.72]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ImeEY-0000Yr-8r; Mon, 29 Oct 2007 19:41:26 -0400 Original-Received: from 203-216-97-240.dsl.gol.ne.jp ([203.216.97.240] helo=catnip.gol.com) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1ImeEV-0006xX-LL; Tue, 30 Oct 2007 08:41:23 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 4F99D2F4C; Tue, 30 Oct 2007 08:41:22 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: (Eli Zaretskii's message of "Mon\, 29 Oct 2007 21\:46\:18 +0200") Original-Lines: 32 X-Abuse-Complaints: abuse@gol.com X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82111 Archived-At: Eli Zaretskii writes: >> This also seems be a good opportunity abandon K&R C. >> >> I am not looking for an "opportunity" to do this. > > Btw, we can have the cake and eat it, too, by using the P_ macro > (defined on lisp.h). I think compiling Emacs using a K&R-only compiler has been impossible for a long time anyway, as many Emacs functions have been written in ANSI style with no regard for K&R-compatibility. Nobody has complained. Morever, it would probably take a fair amount of work to make Emacs compile with a K&R compiler again. If there are actually any K&R-only compilers left (are there?!), it's likely they're so crufty/out-of-date/underfeatured that they'd never be able to handle Emacs anyway. It doesn't seem worth it to me to _rewrite_ existing K&R-style definitions -- that would just cause a lot of headaches for merging -- but I think it would be good to explicitly state that it's OK to use ANSI-style definitions for new functions or rewrites etc. Using P_ also seems sort of pointless, as it only exists for the benefit of K&R. So I think it would also be good to state that it's unnecessary to use P_ for new function declarations (in headers etc). -Miles -- If you can't beat them, arrange to have them beaten. [George Carlin]