On 12/14/13 12:53, Jakub Jelinek wrote:
Hi!
This patch implements one of the few remaining missing ubsan
sanitizations, in particular instrumentation which complains about
loads of (non-bitfield) bool or enum (the latter in C++ only) value
that is outside of the range allowed (0/1 for bool, min/max for
minimum precision integer type holding all values as the standard says).
Is this still acceptable for trunk (it is missing part of a new feature
in 4.9, doesn't affect code unless one of -fsanitize={undefined,bool,enum}
is used)?
2013-12-14 Jakub Jelinek <ja...@redhat.com>
* ubsan.c: Include tree-ssanames.h, asan.h and gimplify-me.h.
(ubsan_type_descriptor): Handle BOOLEAN_TYPE and ENUMERAL_TYPE
like INTEGER_TYPE.
(instrument_bool_enum_load): New function.
(ubsan_pass): Call it.
(gate_ubsan): Also enable for SANITIZE_BOOL or SANITIZE_ENUM.
* asan.c (create_cond_insert_point): No longer static.
* asan.h (create_cond_insert_point): Declare.
* sanitizer.def (BUILT_IN_UBSAN_HANDLE_LOAD_INVALID_VALUE): New
built-in.
* opts.c (common_handle_option): Handle -fsanitize=bool and
-fsanitize=enum.
* builtins.c (fold_builtin_memory_op): When sanitizing bool
and enum loads, don't use enum or bool types for memcpy folding.
* flag-types.h (SANITIZE_BOOL, SANITIZE_ENUM): New.
(SANITIZE_UNDEFINED): Or these in.
* c-c++-common/ubsan/load-bool-enum.c: New test.
As you note, there's some question as to whether or not this should be
acceptable for 4.9. Yes it's well contained, but we really need to draw
the line. Is this the last thing for the sanitizers that is still under
consideration?
Also, doesn't C allow objects with an enum type to contain values not in
the enumerated value list? Do TYPE_MIN/TYPE_MAX give the range of the
enums or the range of the underlying mode for the object?
jeff
