From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Science to suppress compiler warnings Date: Wed, 03 Jun 2009 13:43:30 +0900 Message-ID: <87zlcqgc5p.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fxeigro9.wl%xma@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1244004010 23950 80.91.229.12 (3 Jun 2009 04:40:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Jun 2009 04:40:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Xavier Maillard Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 03 06:40:06 2009 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 1MBiGk-0001rQ-EE for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2009 06:40:06 +0200 Original-Received: from localhost ([127.0.0.1]:35322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBiGj-0007rd-Hc for ged-emacs-devel@m.gmane.org; Wed, 03 Jun 2009 00:40:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBiGb-0007ma-Fb for emacs-devel@gnu.org; Wed, 03 Jun 2009 00:39:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBiGW-0007gv-BR for emacs-devel@gnu.org; Wed, 03 Jun 2009 00:39:56 -0400 Original-Received: from [199.232.76.173] (port=58835 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBiGW-0007ge-1B for emacs-devel@gnu.org; Wed, 03 Jun 2009 00:39:52 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:59963) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBiGT-0002MG-EF; Wed, 03 Jun 2009 00:39:49 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 014951537B8; Wed, 3 Jun 2009 13:39:46 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 76E9E1A2645; Wed, 3 Jun 2009 13:43:30 +0900 (JST) In-Reply-To: <87fxeigro9.wl%xma@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/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:111304 Archived-At: Xavier Maillard writes: > Elisp manual at "Compiler Errors" section (16.6) says we should > conditionalize variable use with a boundp test (same thing for > undefined function) but I find it very unpractical. If this is related to your work on supporting old versions of Emacs, my advice is "live with it". Either use the runtime test if it's an Emacs-defined variable, or use an appropriate `defvar' or `defconst' to initialize the variable. Suppressing compiler warnings is very likely to lead to runtime errors, often intermittent ones. Eg, there may be an unusual code path that leads to reference to a void variable very early in an Emacs session. Boom! But unless you type that exact sequence of commands immediately after starting Emacs, something requires the relevant library, and no problem can be found. Such bugs are quite hard to diagnose, even to localize, if the user is not an Emacs expert. A boundp check with a good error message, or a proper initialization with `defvar', will prevent or at least help diagnose a lot of problems. > I thought (probably was wrong) that: > > (eval-when-compile (defvar foo nil)) > > would do the trick. Is it the correct way to avoid warnings ? If you don't understand what this does, I have to recommend avoiding this trick. It's a dangerous optimization, not a fix. This kind of warning suppression is a *white lie* to Lisp. If you know what you're doing, and you're desperate for space savings, it may be useful. Otherwise, you're just asking for trouble. Just defvar at loadtime (costless) or require the defining library (usually at a fairly small space cost).