[Info-vax] [OT?] Should compiler warnings be treated as errors ?

[Craig A. Berry]

On 9/10/21 4:28 AM, hb wrote:
> On 9/10/21 4:17 AM, John Reagan wrote:
>> On Thursday, September 9, 2021 at 8:30:16 PM UTC-4, Craig A. Berry wrote:
>>
>>>
>>> I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
>>> compiler for code that produces no warnings with current gcc and clang.
>>> And of course compiler warnings get escalated to linker errors on VMS,
>>> so what Linux is considering now has effectively already been the case
>>> on VMS for a few decades.
>>
>> Linker warnings.
>>
>> And you can clear that with SET IMAGE /SUCCESS
>>
> 
> John already answered, but I've seen this so many times, so I'll expand
> on that. They get escalated to linker warnings, not errors. The linker
> produces an image file. You will not get one if the linker encounters an
> error. And the image activator will active the image without printing
> any message, no matter if it is a main image or a shareable. Only if you
> try to find a symbol in the image file with lib$find_image_symbol you
> will get a warning: %LIB-W-EOMWARN. Yes, a %LIB not a %SYSTEM.

Yes, I mixed up where the escalation happens.  It is not the linker but
the build utility that turns warnings into errors and stops the build in
its tracks unless you take extra steps to get around it.  A recent
real-world example:

Link /Debug/Trace/Map 
/Shareable=[---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE 
CN.opt/Option,[---]perlshr_attr.opt/Option
%LINK-W-SHRWRNERS, compilation warnings ␍␊      in shareable image file 
D0:[CRAIG.blead]DBGPERLSHR.EXE;1
%MMK-F-ERRUPD, error status %X10648268 occurred when updating target 
[---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE
%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target SUBDIRS
%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target SUBDIRS
Unsuccessful make(cpan/Encode): code=1024 at make_ext.pl line 584.
%NONAME-F-NOMSG, Message number 0C14803C
%MMK-F-ERRUPD, error status %X0C14803C occurred when updating target DYNEXT

You can of course force MMK or MMS or a command procedure to ignore
warnings and continue, or you can ignore the status of failed
subprocesses in whatever top-level driver is running those things.  But
that is not what happens by default.

> And you can restore any cleared warning with SET IMAGE /RESTORE.

Of course there are ways to put your head in the sand if you want to,
for example cc/nowarn, and there are certainly development scenarios
where temporarily ignoring a warning and moving on is the right thing to
do.

My point was that on VMS compiler warnings stop the build unless you
take extra steps to prevent that from happening.  On other platforms,
all the warnings are equivalent to informationals with DEC C -- nothing
happens unless you review the compiler output or, as Linux is apparently
now doing, explicitly escalate the warnings to errors.