At 9:40 AM +1100 2/6/03, Keirnan, Paul wrote:
>Could some kind soul please tell me why a 'warning' poses a problem.
>The compiler should have produced usable output, shouldn't it?
>
>While I agree that it is best to fix these (warnings), would the end
>result have been any different if '/NOWARN' was used.

Possibly, depending on the warning.  I suspect that for mismatches
between storage class modifiers like "const" the generated code would
produce the same result but possibly have different optimizations.
For other common warnings, such as comparing an unsigned integral
value to a negative number, the code very likely has a bug.

>In other words, when I am doing 'Perl' builds, should I always be
>wary of any C compiler warnings.

Yes, be wary.  Basically a warning means the compiler is telling you
the output may or may not be usable and you should fix the code to
rectify the situation.  By default, VMS build tools take a very
conservative approach.  The compilers run with all warnings enabled
by default.  The linker issues further warnings if it encounters
object code that compiled with warnings.  MMS and MMK stop dead in
their tracks when executing a command (including a compile or link
command) that generates a warning.

Having said all that, if you are in a hurry to get a Perl extension
up and running and it is giving you compiler warnings in a a section
of code you can't make sense of, you can certainly breeze past the
warnings and see if it passes all its tests.  That may be good
enough, or not.  It's impossible to give a general answer to that
since it depends on what the extension is, what you're going to do
with it, and what the warning is.

Note that if you do want to skip warnings (temporarily or otherwise),
you should just be able to issue "MMS" or "MMK" again; the object
file will be up-to-date so the compile that generated warnings won't
run again and the rest of the build will proceed.  Ditto for link
warnings.
-- 
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to