This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: array bounds, sanitizer, safe programming, and cilk array notation


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]