Sorry for late reply - I've found this in my inbox only today.
On Mon, Jan 26, 2015 at 11:53:59AM -0800, Martin Uecker wrote:
>
> Hi all,
>
> I am writing numerical code, so I am trying to make the use
> of arrays in C (with gcc) suck a bit less. In general, the long term
> goal would be to have either a compile-time warning or the possibility
> to get a run-time error if one writes beyond the end of an array as
> specified by its type.
>
> So one example (see below) I looked at is where I pass an array of
> too small size to a function, to see how see can be diagnosed. In some
> cases, we can get a runtime error with the address sanitizer, but this
> is fairly limited (e.g. it does not work when the array is embedded
> in a struct) and I also got mixed results when the function
> is inlined.
>
> For pointers to arrays with static size one can get an "incompatible
> pointer" warning - which is nice. With clang, I also get warning for
> pointers which are declared as array parameters and use the 'static'
> keyword to specify a minimum size. This a diagnostic we are currently
> missing.
>
> The next step would be to have diagnostics also for the VLA
> case if the size is known at compilation time (as in the
> example below) and a run-time error when it is not (maybe
> with the undefined behaviour sanitizer?).
>
> If we have the later, I think this might also help with safer
> programming in C, because one would get either a compile time or
> runtime error when I passing a buffer which is too small to
> a function. For example, snprintf could have a prototype like
> this:
>
> int snprintf(size_t size; char str[static size], size_t size,
> const char *format, ...);
>
> That VLAs essentially provide the bounded pointer type C is
> missing has been pointed out before, e.g. there was a proposal
> by John Nagle, although he proposed rather intrusive language
> changes (e.g. adding references to C) which are not necessary
> in my opinion:
>
> https://gcc.gnu.org/ml/gcc/2012-08/msg00360.html
>
>
> Finally, what is missing is a way to diagnose problems inside
> the called functions. -Warray-bounds=2 (with my recently
> accepted patch) helps with this, but - so far - only for static
> arrays:
>
> void foo(int (*x)[4])
> {
> (*x)[4] = 5; // warning
> }
This is detected by -fsanitize=object-size, turned on by default in
-fsanitize=undefined. Since it makes use of __builtin_object_size,
it is necessary to compile with optimizations turned on.
> It would be nice to also have these warning and runtime errors
> (with the undefined behaviour sanitizer) for VLAs.
>
> Finally, I think we should have corresponding warning also
> for pointers which are declared as array parameters:
>
> void foo2(int x[4])
> {
> x[4] = 5;
> }
Ditto.
> The later does not currently produce a warning, because x
> is converted to a pointer and the length is ignored.
>
> If it is not possible to have warning here for compatibility
> reasons, one possibility is to have an extension similar to
> 'static' which makes 'x' a proper array in the callee, e.g.
I think even the 'static in parameter array declarators' (ugly) C99 extension
isn't properly implemented yet (I don't think that the compiler makes
any optimization based on it).
So - if I understood this correctly - I think it's better to enhance
ubsan than to add any kind of language extensions.
Marek
