Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1634

Re: Second draft, "Safe arrays and pointers for C"

Show all headers | View raw

Usenet followup with a PDF as quoted text sure is difficult. Bad formatting
in the quoted material shall be blamed on pdftotext, iconv, and the bastards
what invented PDF in the first place. I fixed it up just enough to be
readable.

The PDF allegedly says:
>Safe arrays and pointers for C through compatible additions to the language
>John Nagle Discussion draft, round 2- August/September, 2012
>
>Introduction
>Buffer overflows continue to plague C and C++ programs.
                                                        ^
                                                        |
[citation needed]---------------------------------------/

Seriously, got any statistics to support this? What's the percentage of bugs
(or percentage of security holes in particular) that are buffer overflows?
Has this percentage gone up or down over the last 5,10,15,20 years? Would a
stricter language actually have prevented any recent buffer overflow bugs, or
are they caused by programmers failing to use strict compiler modes and other
static analysis tools that are already available for C as it is?

With words like "plague" and no actual numbers, the whole basis for the
proposal looks like a personal grudge.

>Features imported from C++11
>o o o References auto decltype

I don't do C++. Is decltype just a respelling of typeof?

I do know C++ reference syntax and it's stupid. Given this declaration:

int i, j[10], k[3][3], *p, **pp, foo(int), &r;

All of these expressions have type int:

  i, j[i], k[i][i], *p, *pp, foo(i)

And look who's left out: the &r which doesn't mean what it says.

Importing that misdesigned garbage into C is an insult.

>
>Unions may not contain pointer or reference types, and all parts of a union
>must have the same length.

So unions just became useless...

>
>To be modified by pointer arithmetic, a pointer variable must be initialized
>at declaration to an element of an array. Subscripting a pointer is allowed,
>but the result is read-only ("const").

So after all this effort, unintended read accesses via buffer overflow are
still allowed?

>Fixed-length arrays in C and C++
[...]
>This is valid C++ today. C++ already supports the concept of a reference to
>an array. (Arrays of references are prohibited by the C++ standard, but
>references to arrays are not.) Where the compiler knows the length of an
>array, we can acces that informatio via sizeof. This is convenient, but only

Typos (acces, informatio)

>
>When a known-length array is defined or passed as a parameter, its length is
>the value of the dimension expression evaluated at initialization time. This
>follows the usage for C99 variable length array parameters. This feature
>allows a function such as the following:
>void copybyref(size_t n, int (&a)[n], const int (&b)[n]) {
>  for (int i = 0; i < lengthof(a); i++) {
>    a[i] = b[i];
>  }
>}

There is existing syntax (since C99) that I think you're overlooking for the
prototype:

void copybyref(size_t n, int a[static n], const int b[static n])

>If the programmer calls "copybyref" as follows:
>copybyref(lengthof b0, b0, a0);
>The checks become
>lengthof(b0) == lengthof(b0)
>engthof(a0) == lengthof(b0)

Typo (engthof)

>For example, the classic UNIX read call would now be expressed as:
>int read(size_t n; int fd, void_space(&buf)[n], size_t n);
>(The type void_space is discussed below; it's simply a type with a size of
>1, usable for arrays, for which the bytes have no predetermined meaning.
>Think of it as void* with length. The initial "size_t n;" is a forward
>declaration, discussed below.)

void_space is like a hybrid between a void and a char... I think I'd call it
"void char" (it fits in with "signed char" and "unsigned char" as another
variant of the basic 1-byte type). And typedef it as vchar or voidc.

>Worth noting is that the function declaration of read above is, in
>non-strict mode, compatible with existing code which passes buf as a pointer
>to a char.

What about existing code which passes a pointer to a struct, and n is the
sizeof the struct (or maybe a multiple of the sizeof the struct)? Do all
pointers convert to void_space &[] as easily as they convert to void *?

>A struct with an array as the last component
>An especially useful idiom is a structure with an array as the last
>component. C supports this now, but the size of the array is always
>undefined, expressed with [ ] . This proposal allows such arrays to be of
>known size. The array, and the structure, then have a known size. and A
>simple example is
>typedef struct msgitem {
>  const size_t len;
>  char itemvalue[len];
>};
>struct msgitem firstmsg = { 100, 0 }; // empty msgitem, size 100

What's that typedef doing there?

This looks nice, but I had an idea for an explicit syntax marker to show that
an earlier struct element is being referred to. The designated initializer
syntax.

struct msgitem {
  const size_t len;
  char itemvalue[.len];
};

I'm not sure this is better.

The const brings up an important point too. Obviously it's meant to prevent
the len being changed after the struct is allocated. Would you disallow the
declaration without the const?

>
>Associating length with an array pointer in a structure
>Alternatively, a user might want a structure which carries both the array
>and its size. The pointer-based form is typedef str { size_t len, char*
>data}; New reference form: typedef str { size_t len, char (&data)[len]); ...
>str s1 = {n, MALLOC(char, n) }; // structure initialization The key point
>here is that char (&data)[len] is a reference to a string of known length.
>As in the previous example, len, is an element in the same structure, and
>ties the length of the array to a value which can be found from the
>structure. Multiple arrays may be present in the same structure. However,
>all such arrays must be allocated during structure initialization, because a
>reference cannot be null.

Here I think you're reaching too far. You can't just decree that a bunch of
dynamic allocations succeed or fail as some kind of atomic group. You have to
allow for cleanup after the first one succeeds and the second one fails. And
the more you try to hide that cleanup, the less like C your language becomes.

>From Numerical Recipes in C, Gauss-Jordan elimination:
>Original function declaration:
>void gaussj(float **a, int n, float **b, int m);
>New form:
>void gaussj(int m; float (a&)[n][n], int n, float (&b)[n][m], int m);

Are those meant to be ABI-equivalent? I don't see how they can be. The first
one implies that there is actually an array of pointers to float somewhere in
memory, and that the full two-dimensional array of floats doesn't have to be
contiguous.

-- 
Alan Curry

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-30 12:48 -0700
  Re: Second draft, "Safe arrays and pointers for C" pacman@kosh.dhis.org (Alan Curry) - 2012-08-31 22:17 +0000
    Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-31 17:26 -0700
      Re: Second draft, "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-09-02 22:20 +0200
        Re: Second draft, "Safe arrays and pointers for C" BGB <cr88192@hotmail.com> - 2012-09-03 10:55 -0500
          Re: Second draft, "Safe arrays and pointers for C" Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 16:39 +0000
            Re: Second draft, "Safe arrays and pointers for C" BGB <cr88192@hotmail.com> - 2012-09-03 13:18 -0500
  Re: Second draft, "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 10:52 +0200
  Re: Second draft, "Safe arrays and pointers for C" Per <per.mathisen@gmail.com> - 2012-09-28 06:49 -0700
    Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-09-28 11:36 -0700
      Re: Second draft, "Safe arrays and pointers for C" Per <per.mathisen@gmail.com> - 2012-10-01 09:38 -0700
        Re: Second draft, "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-10-01 11:38 -0700
      Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 09:11 -0500
        Re: Second draft, "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-12-17 10:18 -0800
          Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 18:24 -0500
            Re: Second draft, "Safe arrays and pointers for C" Shao Miller <sha0.miller@gmail.com> - 2012-12-17 18:32 -0500
            Re: Second draft, "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-12-17 15:44 -0800

csiph-web