From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id B636DBC88 for ; Fri, 11 Feb 2005 01:48:59 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j1B0mxW2026785 for ; Fri, 11 Feb 2005 01:48:59 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA13305 for ; Fri, 11 Feb 2005 01:48:59 +0100 (MET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j1B0mu1a023240 for ; Fri, 11 Feb 2005 01:48:58 +0100 Received: from [192.168.1.200] (ppp212-197.lns2.syd3.internode.on.net [203.122.212.197]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j1B0miBw026885 for ; Fri, 11 Feb 2005 11:18:54 +1030 (CST) Subject: Warning options From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list Content-Type: text/plain Message-Id: <1108082923.16698.184.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 11 Feb 2005 11:48:44 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 420C00FB.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 420C00F8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; sourceforge:01 ocaml:01 gcc:01 cvs:01 ocaml:01 cvs:01 flags:01 compiler:01 compiler:01 flags:01 glebe:01 wwww:98 061:98 nsw:01 snail:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Ocaml appears to be following the same path as gcc with respect to warnings: if a warning option isn't recognized it is reported as a hard error. This feature creates an unnecessary upwards compatibility barrier, and I request the INRIA team consider fixing it. The correct strategy is to generate a warning, but continue compiling anyhow. The alternative is to use 'autoconf' style configuration checks in all build configurations (which is I hate) This problem affected me as follows: (a) I am using CVS Ocaml (b) There is a new warning Y -- unused variable added to the CVS version of Ocaml (c) I have lots of code, some not written by me, which triggers that warning, and in the clutter I actually missed an important warning (incomplete match) (d) I put -w y to disable the warning (e) My client can't build the code now, because he isn't using the CVS version of Ocaml, his version doesn't support the new warning Warning flags should be treated like #pragma in C: the compiler is *required* to ignore one it does not recognize. My comment does not apply to compiler options with a semantic impact, however warnings are purely a quality of implementation issue (QUI). Ignoring bad warning flags is also mandatory for upwards compatility in cases where the implementor wishes to remove a warning. My suggestion is simply that in this case only: -w ? the value of ? is used if possible, and a warning printed if this version of the compiler doesn't know what it means, alternatively ignore it completely, or provide a new warning like -w W w which disables/enables the warning about bad warning flags depending on the default (kind of complex ..) -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net