On Sat, 15 Feb 2025 21:30:16 +0000
Sam James <s...@gentoo.org> wrote:
> > +cbl_refer_t *
> > +negate( cbl_refer_t * refer, bool neg = true ) {
> > + if( ! neg ) return refer;
> > + assert( is_numeric(refer->field) );
>
> These should be gcc_assert or gcc_checking_assert in general,
> depending on the severity (do you want to always assert the
> invariant, or is it okay to only do it for debugging ('checking')
> builds of the compiler)?
I would like to explain what you're seeing, and hope to convince you it's for
the best.
There are two issues here, the form of the assert, and the purpose.
By design, the lex & yacc parts of the COBOL front end are pure Posix.
Originally they didn't use any gcc header files. The reader of these files
should be able to read them with no knowledge of gcc internals. After all,
that reader was once me. :-)
In addition to being bog-standard C, assert(3) does something gcc_assert does
not: it prints the text of the asserted condition. That plus the stack trace
is more interesting to me than the source line. I don't remember the last time
I cared about the COBOL input to track down an invariant.
That brings us to the purpose. This assert and many others are guarded by the
yacc grammar. Before the parser calls cbl_refer_t::negate, it should have
ensured that the input is numeric, because non-numeric input is a semantic
error (not syntax error) in the COBOL that the parser reports through the
diagnositic framework. IOW, we're only asserting that the parser did its job
correctly.
cscope reports 465 uses of assert(3) in our front end. I honestly believe gcc
is best off leaving them exactly as they are. They are an aid to the
developer, mostly to enforce preconditions. The user should never see the
message and if he does no amount of friendliness is any help. A developer will
have to correct the logic error.
--jkl
