Request for comments on language extension: Safe arrays and pointers for C.

[Joseph S. Myers]

On Fri, 31 Aug 2012, John Nagle wrote:

> On 8/31/2012 3:32 PM, Joseph S. Myers wrote:
> > My comments are:
> >
> > * TL;DR.
> 
>    Then, perhaps, commenting is premature.

The alternative would have been to ignore your message completely (having 
already concluded based on the initial comp.std.c discussion that there 
was unlikely to be much of interest here); it seemed better to give 
outline thoughts about the deficiencies of the proposal and why we can't 
give sensible effort estimates.

> > * No specification given at the level of edits to C11.
> 
>    That's correct.  This is still an informal proposal.

Our experience is that extensions that have only been described informally 
are especially likely to be problematic; they need specifications at the 
level of standard edits, carefully developed with experience of C 
standards work.

Adding references to C would likely have consequences throughout the 
entire language standard.  Producing the proper specification for this 
would be a large amount of work for someone with extensive expertise in 
the standard (and in the C++ standard, for comparison), and is 
prerequisite for producing implementation effort estimates, which as I 
noted is also a large amount of work.

> > * How does this relate to various cases in the secure coding rules
> > draft TS (a specification for static analyzers, but should still be
> > relevant here if you can point to examples of bad code therein that
> > would be detected reliably through use of your proposals)?
> 
>    The "Arrays" section of the CERT guide,
> https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=263
> is a style guide, not a spec for hard checking. See
> "ARR30-C. Do not form or use out of bounds pointers or array subscripts".

I'm referring to ISO/IEC draft TS 17961 (e.g. WG14 N1624).

>     Reading onward to page 17 of the paper, where SAL, Cyclone, and

You need to make the compelling, self-contained case from page 1, not page 
17.

>     That may happen, but I'm still getting comments informally at
> this point.  I'd like to see enough of this implemented in GCC
> as an extension that people could try it out.

You're welcome to write patches, but we are extremely unlikely to want to 
put anything as wide-ranging as references for C in the mainline sources 
without a compelling case in terms of actual standard adoption or 
widespread use of code using the extension, and unlikely to put in the 
days or weeks of work required to define the feature properly or produce 
an implementation design and effort estimates without a much better case 
made for the feature.

-- 
Joseph S. Myers
joseph@codesourcery.com