[Bug c/96054] New: RFE: __attribute__((fatal))

[Bug c/96054] New: RFE: __attribute__((fatal))

[hpa at zytor dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054

            Bug ID: 96054
           Summary: RFE: __attribute__((fatal))
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hpa at zytor dot com
  Target Milestone: ---

__attribute__((error)) and __attribute__((warning)) are useful, but have, in
some places, poor semantics. It would be really good to have a function
attribute which would trigger if "all roads lead to Rome", but would allow the
function to be called dynamically at runtime under other circumstances. A good
example on when this applies is a failure case in a default statement of a
switch, or as a way to trap assert() at compile time.

Specifically, to avoid impossible-to-analyze conditions involving functions
never called and functions potentially not returning (e.g. calling longjmp()),
I propose the following semantics:

"For any function that is itself not marked "fatal", if the compiler can
determine at compile time that there exists no control flow path between
function entry and function return that does not call a function marked
"fatal", issue a compile-time diagnostic."

This diagnostic would presumably be a warning, that the user can promote to
error during development.

There may be better way to accomplish this, but something like it would be very
useful.


For example:

extern void __attribute__((noreturn,fatal)) panic(void);
extern void myfunc(void);
extern int stuff(void);
extern int more_stuff(void);

int foo(int x)
{
    x &= 3;

    myfunc();

    switch (x) {
        case 4:
             x = stuff(); break;
        case 5:
             x = more_stuff(); break;
        case 6:
             break; /* leave x unchanged */
        default:
             panic(); break;   /* we can catch this error at compile time! */
     }

     return x;
}

[Bug c/96054] RFE: __attribute__((fatal))

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054

--- Comment #1 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to H. Peter Anvin from comment #0)
> __attribute__((error)) and __attribute__((warning)) are useful, but have, in
> some places, poor semantics.

__attribute__((error)) produces an error. __attribute__((warning)) produces a
warning. It seems to me that, if following this pattern of attributes being
named after the kind of diagnostic they produce, __attribute__((fatal)) ought
to produce a fatal diagnostic that terminates compilation. Having it do
something else would seem to violate expectations for me...

[Bug c/96054] RFE: __attribute__((fatal))

[hpa at zytor dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054

--- Comment #2 from H. Peter Anvin <hpa at zytor dot com> ---
I agree, my naming was very poor.
Perhaps "panic" or "abort" would work; those are classic names in software use
for this.

Another case of a function that could be so attributed would be the function
typically called __assert_failed().

It is probably worth noting that all the ones I can think of should be noreturn
functions. I don't know if that is truly inherent, but personally I cannot
think of a case where it would not be.