On Mon, 16 Dec 2013, Jakub Jelinek wrote: > On Mon, Dec 16, 2013 at 07:40:16PM +0100, Jakub Jelinek wrote: > > It can be the last thing, sure. I think the still unimplemented and > > potentially useful are the floating point overflow sanitization (haven't > > looked yet what exactly it is, I suppose casts from floating point to > > integers where the values are out of range, but dunno exactly) and > > they have also some __builtin_object_size based bounds checking. > > Oh, and then there is sanitization of nonnull arguments and returns_nonnull > return values which ideally we should add, clang doesn't have it (yet?), but > it is really desirable when we aggressively optimize based on those > attributes. We need to discuss with compiler-rt ubsan upstream first > though, unless we want to add the entrypoint as a GCC only libubsan addition.
I think there's probably more for future versions once you get into adding new entry points. See e.g. <http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01162.html> about not being able to check systematically that the size in bytes of a VLA, including a constant-size array of VLAs, does not exceed target PTRDIFF_MAX, for lack of libubsan support. More generally: look at the list of undefined behavior in C11 J.2. For each item there, it should be possible to say one (or more) of: * GCC bounds the effects of this undefined behavior. * This undefined behavior is detected at runtime with (specified sanitization option). * This undefined behavior is critical undefined behavior as defined in L.3. Perhaps a table to that effect, along with one for GCC extensions for which sanitization could usefully apply, should go on the wiki. We could then see what sanitization (or other bounding) features are needed in order to provide an option / options that would conform to Annex L and define __STDC_ANALYZABLE__. -- Joseph S. Myers jos...@codesourcery.com
