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.
> > 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.
Jakub
