From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32687 invoked by alias); 21 Feb 2015 15:21:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32678 invoked by uid 89); 21 Feb 2015 15:21:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 21 Feb 2015 15:21:30 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1LFLLUa001151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 21 Feb 2015 10:21:21 -0500 Received: from redhat.com ([10.40.204.30]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1LFLFnd013055 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2015 10:21:18 -0500 Date: Sat, 21 Feb 2015 15:21:00 -0000 From: Marek Polacek To: Martin Uecker Cc: gcc Mailing List , Jeff Law , Joseph Myers , Jakub Jelinek , Florian Weimer , "Balaji V. Iyer" Subject: Re: array bounds, sanitizer, safe programming, and cilk array notation Message-ID: <20150221152115.GA18668@redhat.com> References: <20150126115359.295659da@lemur> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150126115359.295659da@lemur> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-02/txt/msg00206.txt.bz2 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