This is the mail archive of the
mailing list for the GCC project.
Re: array bounds, sanitizer, safe programming, and cilk array notation
- From: Marek Polacek <polacek at redhat dot com>
- To: Martin Uecker <uecker at eecs dot berkeley dot edu>
- Cc: gcc Mailing List <gcc at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, "Balaji V. Iyer" <balaji dot v dot iyer at intel dot com>
- Date: Sat, 21 Feb 2015 16:21:15 +0100
- Subject: Re: array bounds, sanitizer, safe programming, and cilk array notation
- Authentication-results: sourceware.org; auth=none
- References: <20150126115359 dot 295659da at lemur>
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
> 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
> 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:
> 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
> void foo(int (*x))
> (*x) = 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)
> x = 5;
> 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.