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