This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Request for comments on language extension: Safe arrays and pointers for C.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: John Nagle <nagle at animats dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 31 Aug 2012 22:32:39 +0000
- Subject: Re: Request for comments on language extension: Safe arrays and pointers for C.
- References: <504132D4.6080003@animats.com>
My comments are:
* TL;DR.
* No specification given at the level of edits to C11.
* At a glance, no or inadequate explanation of why library solutions and
appropriate coding practices (such as the use of managed string libraries)
are inadequate.
* How does this compare to the array size checking you get with
_FORTIFY_SOURCE in glibc (and associated GCC extensions)?
* 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)?
* Why hasn't this been done before - what is so novel that avoids the
pitfalls encountered by previous related work? An insightful analysis of
such work and the issues - not necessarily technical - with it is needed
to demonstrate there is a genuine difference here.
* Is this really in accordance with the Spirit of C?
* In general we're skeptical of new language extensions given the problems
historically associated with past ones. Assessing what pitfalls there
might be in a proposal and the work required to implement it is itself a
substantial amount of work (I'd guess several hours at least for this
document); it's more likely to happen if there's something to excite
people about the proposal (as well as if all the other issues I list are
addressed), and I don't see anything particularly exciting here. That's
especially the case given how many previous attempts there have been at
addressing this sort of issue.
* If proposals are written by people with substantial experience in C
compiler implementation they are more likely to be sound - what such
experience has gone into writing this document?
* Consider attending a WG14 meeting and presenting the proposals in person
there (having had them included in a pre-meeting mailing), if you want a
wider range of implementer opinions.
--
Joseph S. Myers
joseph@codesourcery.com