2010/11/29 Rob Hamerling <[email protected]>

>
> You may be right. So far I observed only the difference with the messages
> generated with -warn. But I understood from the announcement msg of Kyle
> that it applies to _error as well.
>

OK, my mistake. _error "zebla" gives:

before:

jal 2.4n (compiled Jun  2 2010)
generating p-code
0 errors, 0 warnings
2560 tokens, 199150 chars; 5299 lines; 9 files
generating PIC code pass 1
generating PIC code pass 2
writing result
jaluino_medium_v2_usb_bootloader_autostart.jal:46: "zebla"
Error while compiling file (status=1).
See previous message.

now:
jal 2.4o (compiled Nov 28 2010)
generating p-code
2560 tokens, 199150 chars; 5299 lines; 9 files
generating PIC code pass 1
generating PIC code pass 2
writing result
jaluino_medium_v2_usb_bootloader_autostart.jal:46: "zebla"
1 errors, 0 warnings
Error while compiling file (status=1).
See previous message.


Note subsequent _error aren't counter, only the first as it stops
compilation on first _error met.


>
> _ It's a good thing _warn messages are now counted. As
>
>> you said, the better option would be the compiler to check restrictions.
>>
>
>  "Hiding" a warning message from device files will cause troubles
>> eventually.
>>
>
> The case I was referring to is the _warn in the device files of only the
> 16f73 and 16f74 (no other device files have this warning).
> For this particular case it is overdone to consider the compilation as
> unsuccessful, therefore I want to remove this warning.
>

Indeed, if it's very limited (as it is), it might be overkill. I thought a
lot more chips were impacted.


> The returncode the compilation is still 0! So we could also decide to only
> check the returncode and ignore warnings in the log file.
> But then we'll violate the rule 'warnings are errors'!


It doesn't surprise me that, at compiling level, exit code remains 0. As for
me, it should be 0. But, at lib design level (and user level), "warnings are
errors" (so they doesn't hide real, important warnings). Ideally, warnings
should be removed in a way or another. Leaving few warnings now will
eventually open the door for more warnings later IMHO. Tracking warning has
also helped improving libs&compiler IIRC.

Cheers,
Seb

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to