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
next 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