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 jos...@codesourcery.com
