From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: DEFU* macro name for a extern DEFUN: DEFUE? DEFUNEX? Date: Sun, 10 Apr 2011 23:37:43 -0700 Organization: UCLA Computer Science Department Message-ID: <4DA2A1B7.4080103@cs.ucla.edu> References: <4DA295DB.20709@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1302503882 24058 80.91.229.12 (11 Apr 2011 06:38:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 11 Apr 2011 06:38:02 +0000 (UTC) Cc: Emacs-Devel devel To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 11 08:37:58 2011 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.69) (envelope-from ) id 1Q9Al4-0007jy-KK for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 08:37:58 +0200 Original-Received: from localhost ([127.0.0.1]:38609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9Al4-0007ax-2W for ged-emacs-devel@m.gmane.org; Mon, 11 Apr 2011 02:37:58 -0400 Original-Received: from [140.186.70.92] (port=59206 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q9Aku-0007XB-Nv for emacs-devel@gnu.org; Mon, 11 Apr 2011 02:37:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q9Akt-0001he-A5 for emacs-devel@gnu.org; Mon, 11 Apr 2011 02:37:48 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:41455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q9Akr-0001h6-I3; Mon, 11 Apr 2011 02:37:45 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B75AB39E80F5; Sun, 10 Apr 2011 23:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGNJLs45oH+c; Sun, 10 Apr 2011 23:37:43 -0700 (PDT) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 5281139E80B1; Sun, 10 Apr 2011 23:37:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:138372 Archived-At: On 04/10/2011 11:27 PM, Dan Nicolaescu wrote: > Are you using gcc ? If yes, and you are cleaning up the code to not > generate warnings with some -W flags, how about adding those flags to > the default set so that we do not regress? (configure only sets very few -W > flags now, it could set more...) Sure, I can do that. However, I'm using quite a few flags, and they are likely to cause problems during a normal "configure; make" if they're made the default. Even if a maintainer does a clean build on (say) RHEL 5.6 it's likely that there will be lots of annoying warnings when an installer runs on (say) Solaris. What I plan to do is what other GNU packages do in this situation, namely, add an --enable-gcc-warnings option to "configure". The default is no warnings, but if you set the configure-time option you get lots of nice warnings. > How about the more explicit DEFUN_EXTERN and document DEFUN as > generating a static function? Sure, that'd be easy. >> +#define INFUN(fnname, maxargs) \ >> + static Lisp_Object fnname DEFUN_ARGS_ ## maxargs > > How about nothing instead of INFUN? > Explicit prototypes are much easier to read, and easier to figure out > the calling convention. Yes, that'd also be easy.