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

Groups > comp.std.c > #1740

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

Show all headers | View raw

On August 30th, 2012, at 12:23:29, John Nagle published:
> Safe arrays and pointers for C through compatible additions to the language

Some feed-back, if you care:

I don't really care for importing references from C++11.  C has long 
passed by value (with the exception of arrays [which itself has an 
exception in C89/C90]).

Importing references might mean losing the ability to advise a 
C-newcomer with a keyboard-shortcut that does "C passes by value."

You had a C++ code example:

>   int arr100[100]; // an array of 100 ints
>   arr100& arr100r; // ref to array of 100 ints

My C++ is too rusty to know if there is an error here, or not.  If it's 
really the case that you can do:

   sometype someobj;
   someobj& someobjref;

Then that'd certainly make for some interesting syntactical differences, 
in C!  Does 'someobj&' become a 'type-name'?  If so, at what stages is 
it an incomplete or complete object type?  Can the same be done with 
function identifiers?  Can it be confused for something like:

   (void) (someobj & undeclared_identifier);

?  Is the type of 'someobjref' 'sometype *'?  If so, can its value be 
reset, or is it 'sometype * const'?  How might you declare a reference 
like this as part of a 'struct' or 'union' type definition?

>   void copybyref(size_t n, int (&a)[n], const int (&b)[n])
>   {
>       for (int i = 0; i < lengthof(a); i++)
>       {   a[i] = b[i]; }
>   }

Before jumping right into using '&' in the parameters, I think it'd ease 
my understanding of the proposal if I didn't have to read all of C++11 
just to understand what "references" are, and how they work.  That is, 
the proposal is for C, but the easy import of references from C++11 mean 
that the proposal-reader (probably interested in C) is at a disadvantage 
if they're not familiar with C++11's references.

Considering this particular code example, it must be leading up to an 
eventual alternative, as 'n' appears to make 'lengthof(a)' unnecessary.

It might be interesting if there was a way to just have 'a' and 'b' 
parameters, and to have some mechanism that is independent of your 
proposal's material to ensure that the types of 'a' and 'b' are 
compatible (or have the same size, or whatever) at the call-site.  A 
macro with '_Generic' might help, but perhaps something a little less 
cluttered.

> int read(size_t n; int fd, void_space(&buf)[n], size_t n);

This must still be leading up to something, as 'n' is still being passed...

With the proposed forward declaration idea, can initializers go in 
there?  What about declaring identifiers just for fun but that aren't 
used by the parameters?  Can linkage and storage be specified in those 
forward declarations?  What about declaring functions and enums in there?

>   int b[100]; // array of 100 ints
>   ...
>   int (&rb)[lengthof(b)] = b; // ref to array b
>
> Assignments to references are subject to type checking

Did you mean "initializers" or did you really mean assignments?

> Conversion from anything which can be NULL to a reference implies a run-time constraint
> check

That C++ references offer any protection against having "null 
references" has been discussed in comp.lang.c and, I hope, dismissed. 
You might be interested in "Null References in C++" at this "Code 
snippets" page: http://www.iso-9899.info/wiki/Code_snippets

I recognize that you are suggesting this "strict mode" as a value-adding 
mode, so I can appreciate that the "code snippets" example might also be 
caught by some C++ implementations employing a similarly valuable mode.

> To be modified by pointer arithmetic, a pointer variable must be initialized at declaration to an
> element of an array

(Presumably "to an element" should be "to point to an element".)

So not to the result of an allocation function, nor to a 'sometype * 
const' that was itself initialized to point to an element of an array, 
right?

> The only allowed values for the pointer variable used in pointer arithmetic are ones which point
> to an element of the array to which it was originally assigned

Did you mean "initialized to point to" or did you really mean "assigned"?

>   int asize = 100; // size wanted
>   int atab[asize]; // declare known-length array
>   asize = 200; // this does not resize the array
>   printf(“Length of atab is %d\n”, lengthof(atab)); // prints 100

'sizeof' does this for VLAs already, so this instance of 'lengthof' can 
be implemented by the usual macro idiom.

>   typedef struct msgitem {
>       const size_t len;
>       char itemvalue[len];
>   };
>   struct msgitem firstmsg = { 100, 0 }; // empty msgitem, size 100

Interesting.  Could the bounds for 'itemvalue' be any kind of expression 
involving any of the previous members' values?  If I already had 'len' 
as a declared identifier just before this 'typedef', would the inner 
'len' hide the outer one?  If so, I gather than any implementation 
already offering VLAs as the last member, as an implementation 
extension, would be incompatible?

Time to move onto something else for a while, but it's been an 
interesting read, so far!  Thanks.  I wonder if you could hack away at 
the proposed changes and reformulate as a series of tiny, digestible 
changes that could accumulate some day and result in the realization of 
the whole.

- Shao Miller

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