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

[John Nagle <nagle at animats dot com>]

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

   Then, perhaps, commenting is premature.

> * No specification given at the level of edits to C11.

   That's correct.  This is still an informal proposal.

> * 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.

   If that approach was going to work, it would have succeeded by now.
Safer C string libraries date back to the 1980s.  New ones are
still being proposed.

> * How does this compare to the array size checking you get with
> _FORTIFY_SOURCE in glibc (and associated GCC extensions)?

   There's a long history of guard-word schemes for detecting
heap overruns, but none have been enormously successful.  The
FORTIFY_SOURCE mechanism is interesting, but can't check the
cases where size information has been lost before the point of
checking.

    With C arrays, the size information is always known at array
creation, but can be lost as the array is passed around.
This proposal is about not losing size information.

> * 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".

> * Why hasn't this been done before - what is so novel that avoids the
>  pitfalls encountered by previous related work?

   That's a good question.  It was tough to fit this into the
existing world of C, C++, and existing code.  It turns out,
however, to be possible.

   It's the addition of C++ references to C that makes this work.
C++ references provide a way to reference arrays without losing
size information.  This proposal merely generalizes C++ references,
along the lines of C variable length arrays, to handle cases where
size information is non-constant.  That provides, at last, a way
to pass arrays around in C without losing size information.

> An insightful analysis of such work and the issues - not necessarily
> technical - with it is needed to demonstrate there is a genuine
> difference here.

    Reading onward to page 17 of the paper, where SAL, Cyclone, and
the Safe C compiler are discussed, may be helpful.  The alternatives
either lead to a new language (like Cyclone), or heavy run time
overhead (like the Safe C compiler).

    Microsoft's Structured Annotation Language provides syntax
for specifying length.  But those are just annotations; they're
not used by the actual code or for checking.  C99 variable
length array parameters also provide syntax for associating
dimension information with arrays passed to function.
But, during conversion to a pointer, the length of the
first dimension is lost.  So the dimension information
passed is just a comment; it's not used, checked, or
accessible within the program.  The only use for that
feature is multidimensional array indexing.

> * Is this really in accordance with the Spirit of C?

    There is a school of thought that celebrates the freedom
of the C programmer to write bad code.  The fact that we have
millions of machines exploited by buffer overflows on a regular
basis perhaps indicates that such freedom can be misused.

> * 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.

   There's certainly a history of failure in this area. That's
why it's worth looking at something that might work.

> * 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.

    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.

				John Nagle
				Animats