On 12/17/2016 02:55 PM, Martin Sebor wrote:
On 12/17/2016 01:01 PM, Markus Trippelsdorf wrote:
I agree that these warnings should probably not be issued, though
it's interesting to see where they come from. The calls are in
the code emitted by GCC, are reachable, and end up taking place
with the right Ubsan runtime recovery options. It turns out that
Ubsan transforms calls to nonnull functions into conditional
branches testing the argument for null, like so:
if (s == 0)
__builtin___ubsan_handle_nonnull_arg();
n = strlen (s);
and GCC then transforms those into
if (s == 0)
{
__builtin___ubsan_handle_nonnull_arg();
n = strlen (NULL);
}
When the ubsan_handle_nonnull_arg function returns to the caller
the call to strlen(NULL) is made.
So I'd like to see more complete dumps here.
This doesn't happen when -fno-sanitize-recover=undefined is used
when compiling the file because then Ubsan inserts calls to
__builtin___ubsan_handle_nonnull_arg_abort instead which is declared
noreturn.
Right. That's what I would expect. If we're going to halt the process
at first UB, then we want to abort. Obviously in that case we're
calling a noreturn function and the strlen never executes.
Otherwise the strlen still needs to be called and whateve action strlen
has when passed a NULL must be preserved.
So the only question in my mind is what was the larger context so that
we can look at why we isolated the paths (which brings the strlen into
the conditional rather than leaving it at the merge point).
jeff
