caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: caml-list <caml-list@inria.fr>
Subject: Warning options
Date: 11 Feb 2005 11:48:44 +1100	[thread overview]
Message-ID: <1108082923.16698.184.camel@pelican.wigram> (raw)

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




             reply	other threads:[~2005-02-11  0:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-11  0:48 skaller [this message]
2005-02-14 17:17 ` [Caml-list] " Damien Doligez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1108082923.16698.184.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).