On 12/19/2016 09:17 AM, Jakub Jelinek wrote:
On Mon, Dec 19, 2016 at 08:52:44AM -0700, Martin Sebor wrote:
Another thing is that what the compiler does can very well just happen
in some generic function that is called by the function that calls these
strlen/strcpy etc. functions (fns with nonnull attribute).

For the string built-ins (though perhaps not for user-defined
nonnull functions), I wonder if it would make sense to have Ubsan
emit an if (p == null) ubsan_handle_nonnull; else strfunc(p); to

That would be just weird, have one behavior for selected subset of functions
and another for the rest?  Ugh.

The selected set of the string built-ins are special -- they are
known not to recover from null pointers so I think treating them
differently would be reasonable (and useful) irrespective of
the -Wnonnull warning.  We don't know what any arbitrary user-
defined nonnull function might do when it gets a null pointer so
skipping those may not make as much sense.

BTW, in the testcase from the Linux kernel it is also path isolation
for error recovery path, something that ought to be predicted unlikely
(though, probably not very unlikely unlike this case), so the question is
if we want to isolate that or not too.

I don't expect to have the cycles to do significant work on this
before stage 3 ends.  For GCC 7, to avoid the Ubsan warnings,
the late -Wnonnull warnings could simply be suppressed when
-fsanitize=undefined is used.  It wouldn't be ideal but it would
be no worse than what GCC does today.  In 8 the warning could be
made smarter to avoid the problem in general.

Or apply the patch I've posted which doesn't suffer from this problem,
or revert the -Wnonnull changes and resolve somehow in GCC 8.

I would prefer your patch if it solves the problem.  In fact,
as I said before, I'm fine with your patch in any case.  I also
still have the patch that I never posted that adds the two levels
to -Wnonnull (keeping -Wnonnull=1 as the default).  And I now have
another patch that simply suppresses the late -Wnonnull warning
when Ubsan checks for null pointers.  I could see about putting
together yet another one to implement the approach I suggested
above but I hesitate to put too much more time into it before
knowing which approach is preferable.

Martin

Reply via email to