[Bug c/111400] New: Missing return sanitization only works in C++

[Bug c/111400] New: Missing return sanitization only works in C++

[david at westcontrol dot com]

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

            Bug ID: 111400
           Summary: Missing return sanitization only works in C++
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

With C++ and -fsanitize=return, the code :

int foo(void) { }

generates a call to __ubsan_handle_missing_return.

For C, there is no sanitizer call - just a simple "ret" instruction.

This is, of course, because in C (unlike C++), falling off the end of a
non-void function is legal and defined behaviour, as long as caller code does
not try to use the non-existent return value.  But just like in C++, it is
almost certainly an error in the C code if control flow ever falls off the end
of a non-void function.

Could -fsanitize=return be added to C?  It should not be included by
-fsanitize=undefined in C, since the behaviour is actually allowed, but it
would still be a useful option that could be enabled individually.

[Bug c/111400] Missing return sanitization only works in C++

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-09-13
     Ever confirmed|0                           |1
                 CC|                            |jsm28 at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
            Version|unknown                     |14.0
           Severity|normal                      |enhancement

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Note C17 disallows a return wotihout an expression for a funcion
that returns a value, not sure if that means falling off the function without a
return (value) is still OK, it at least feels inconsistent.

[Bug c/111400] Missing return sanitization only works in C++

[david at westcontrol dot com]

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

--- Comment #2 from David Brown <david at westcontrol dot com> ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Note C17 disallows a return wotihout an expression for a funcion
> that returns a value, not sure if that means falling off the function
> without a return (value) is still OK, it at least feels inconsistent.

This has all remained unchanged from C99 to C23 (draft), I believe, which makes
things easier!

As far as I can tell, the relevant point in the standards is 6.9.1p12,
"Function definitions", which says "Unless otherwise specified, if the } that
terminates a function is reached, and the value of the function call is used by
the caller, the behaviour is undefined".  

So while a non-void function cannot have a return statement without an
expression (6.8.6.4p1), control flow /can/ run off the terminating }.  I think
this is perhaps a concession to older pre-void C code, when a function that
does not have a return value would still be declared to return "int".

Thus I think gcc's lack of a sanitizer here is technically accurate - but not
helpful, unless you are working with 35 year old code!

[Bug c/111400] Missing return sanitization only works in C++

[schwab@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
You already have -W[error=]return-type.

[Bug c/111400] Missing return sanitization only works in C++

[david at westcontrol dot com]

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

--- Comment #4 from David Brown <david at westcontrol dot com> ---
(In reply to Andreas Schwab from comment #3)
> You already have -W[error=]return-type.

Yes, and that is what I normally use - I am a big fan of gcc's static warnings.

Sometimes, however, there are false positives, or perhaps other reasons why the
programmer thinks it is safe to ignore the warning in a particular case.  Then
sanitizers can be a useful run-time fault-finding aid.  There's certainly a lot
of overlap in the kinds of mistakes that can be found with -Wreturn-type and
with -fsanitizer=return-type, but there are still benefits in have both.  (You
have both in C++, just not in C.)

[Bug c/111400] Missing return sanitization only works in C++

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
To be able to detect this, an ABI change would be needed as you need to pass
back if the function fell through or not. Now for (non-address taken) static
functions that should be ok. The check should happen on the caller side rather
than the callee side as it is only undefined if the caller uses the value ...

[Bug c/111400] Missing return sanitization only works in C++

[sjames at gcc dot gnu.org]

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

--- Comment #6 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to David Brown from comment #4)
> (In reply to Andreas Schwab from comment #3)
> > You already have -W[error=]return-type.
> 
> Yes, and that is what I normally use - I am a big fan of gcc's static
> warnings.
> 
> Sometimes, however, there are false positives, or perhaps other reasons why
> the programmer thinks it is safe to ignore the warning in a particular case.

Note that we now have -Wreturn-mismatch for definite errors.