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

Groups > comp.std.c > #1415 > unrolled thread

Initial draft proposal: "Safe arrays and pointers for C"

Back to article view | Back to comp.std.c

Contents

  Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 11:39 -0700
    Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-13 23:23 +0200
      Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 17:04 -0700
      Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 20:08 -0700
        Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 22:23 -0700
          Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 11:20 -0700
            Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 14:54 -0400
              Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:09 +0200
                Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:00 -0400
              Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:08 -0400
                Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 23:05 -0700
                  Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 06:48 -0400
                    Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 11:22 -0700
                      Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 15:13 -0400
                        Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 13:00 -0700
                          Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:52 +0200
                            Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 17:18 -0400
                              Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:20 +0200
                                Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:40 -0400
                                  Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:04 -0700
                                    Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:35 -0400
                                      Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:47 -0700
                                        Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:52 -0400
                            Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 14:41 -0700
                          Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 12:39 +0100
                            Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 09:57 -0700
                              Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:28 -0400
                              Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 23:52 +0100
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 18:56 +0200
                    Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 19:23 +0200
                    Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-15 21:47 -0700
                      Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:14 +0200
                        Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 20:28 +0200
            Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 15:05 -0400
            Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 21:09 +0200
              Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 13:24 -0700
                Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:39 -0400
                Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 15:23 -0700
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:58 -0700
                Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 00:37 +0200
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:42 -0700
                    Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:57 +0200
                      Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:02 -0700
            Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 14:59 -0700
              Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 15:35 -0700
                Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 00:51 +0200
                  Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:43 +0200
                    Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:31 +0200
                      Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:14 +0200
                Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:58 -0400
                  Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:45 +0200
                    Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:51 -0700
                      Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 07:18 -0400
                        Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:15 +0200
                          Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:28 +0200
                            Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:36 +0200
                              Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:54 +0200
                                Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 15:08 +0200
                              Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:50 -0700
                                Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 23:22 +0200
                                  Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 14:38 -0700
                                    Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 00:51 +0200
                                      Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 16:32 -0700
                                        Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 09:05 +0200
                                  Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:22 -0700
                                    Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 20:29 -0700
                        Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:36 -0700
                          Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 16:09 -0400
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:47 +0200
                Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:33 -0700
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:38 -0700
                    Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:46 +0200
                      Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 22:28 -0700
                      Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:34 +0200
                        Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:12 +0200
            Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 13:09 -0700
              Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 16:21 -0400
                Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 14:22 -0700
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 15:28 -0700
                  Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 19:49 -0400
        Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 08:56 +0200
        Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 06:18 -0400
          Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 12:42 +0200
            Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 09:43 -0700
              Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 19:52 +0200
                Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:03 +0200
              Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:39 +0200
        Re: Initial draft proposal: "Safe arrays and pointers for C" Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-14 08:26 -0400
    Re: Initial draft proposal: "Safe arrays and pointers for C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-13 22:44 +0100
      Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 18:05 -0700
    Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:00 +0200
      Re: Initial draft proposal: "Safe arrays and pointers for C" Marc <marc.glisse@gmail.com> - 2012-08-14 21:18 +0000
        Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 23:51 +0200
    Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 09:40 -0700
      Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-17 21:00 +0200
        Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 13:30 -0700
          Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-17 23:14 +0200
          Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 01:07 +0200
            Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-19 23:14 -0700
              Re: Initial draft proposal: "Safe arrays and pointers for C" Ike Naar <ike@sverige.freeshell.org> - 2012-08-20 07:16 +0000
                Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-20 00:25 -0700
              Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-20 11:49 +0200
              Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-20 22:40 +0200
                Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-20 23:08 +0200
      Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-17 15:33 -0700

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#1487

On 8/15/2012 2:22 PM, Jens Gustedt wrote:
> Am 15.08.2012 21:50, schrieb Keith Thompson:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> [...]
>>> Do you think that implementing a bound check with the [static]
>>> interface for function parameters would be easy to do?
>> [...]
>>
> 
> snip
> 
>> I suppose you could pass implicit bounds parameters, and set them to
>> some distinguished "unknown" value when the bounds aren't available.
>> But then you have incomplete bounds checking, and it can be difficult
>> for the programmer to know when the bounds are actually checked.
>>
>> And what happens if a bound check fails?
>>
>> Or perhaps there's some elegant solution that I'm missing.
> 
> I think you are missing that the bounds checking can be done at the
> calling side. The calling side has seen the interface of the function
> and knows of the restriction.
> 
> It is not perfect and would not easily work with plain pointers that
> are passed as arguments, but it could be implement without any
> additional data if arrays are passed.
> 
> Jens

    Exactly.  That's where I'm going with this.  A key concept
here is to avoid any changes to the ABI, so that old and new
object files can interoperate.

    We plug a few more holes, as shown in the paper, and
offer "strict mode", where only the checkable forms are allowed,
encourage a move to 100% strict mode code in security-critical
applications, and, at last, no more buffer overflows.

    If we can only fix the backwards compatibility problems
with VLAs...

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1489

Am 15.08.2012 23:38, schrieb John Nagle:
> On 8/15/2012 2:22 PM, Jens Gustedt wrote:
>> Am 15.08.2012 21:50, schrieb Keith Thompson:
>>> Or perhaps there's some elegant solution that I'm missing.
>>
>> I think you are missing that the bounds checking can be done at the
>> calling side. The calling side has seen the interface of the function
>> and knows of the restriction.
>>
>> It is not perfect and would not easily work with plain pointers that
>> are passed as arguments, but it could be implement without any
>> additional data if arrays are passed.
>>
>> Jens
> 
>     Exactly.  That's where I'm going with this.  A key concept
> here is to avoid any changes to the ABI, so that old and new
> object files can interoperate.
> 
>     We plug a few more holes, as shown in the paper, and
> offer "strict mode", where only the checkable forms are allowed,
> encourage a move to 100% strict mode code in security-critical
> applications, and, at last, no more buffer overflows.
> 
>     If we can only fix the backwards compatibility problems
> with VLAs...

Perhaps, as a mode of operation, you could just assume that VLA are
part of the language :) And that actually what you are proposing would
make them much more useful and widely adaptable?

A strict mode could require that the visible prototype for a function
with VM types in the argument list (BTW they are never VLA themselves,
but pointers to VLA) should have the same expression as the definition
of the function, and that these expression should be such that their
evaluation could already take place at the point of declaration
without changing the value. Something like it should only contain

- other parameters already declared previously in the list
- integer constant expressions that can be evaluated at declaration of
  the first prototype
- maybe also evaluations of global variables that are known at the
  declaration of the first prototype, but I am less sure for this part

I would claim that this is good style for programming with VM, anyhow.
But since all these requirements would be for strict mode only, so
this wouldn't create incompatibilities with existing code.

Then all the computations for bounds could again be done at the
calling side without changing the ABI, we still would only pass
pointers around.

Jens

[toc] | [prev] | [next] | [standalone]

#1490

On 8/15/2012 3:51 PM, Jens Gustedt wrote:
> Am 15.08.2012 23:38, schrieb John Nagle:
>> On 8/15/2012 2:22 PM, Jens Gustedt wrote:
>>> Am 15.08.2012 21:50, schrieb Keith Thompson:
>>>> Or perhaps there's some elegant solution that I'm missing.
>>>
>>> I think you are missing that the bounds checking can be done at the
>>> calling side. The calling side has seen the interface of the function
>>> and knows of the restriction.
>>>
>>> It is not perfect and would not easily work with plain pointers that
>>> are passed as arguments, but it could be implement without any
>>> additional data if arrays are passed.
>>>
>>> Jens
>>
>>     Exactly.  That's where I'm going with this.  A key concept
>> here is to avoid any changes to the ABI, so that old and new
>> object files can interoperate.
>>
>>     We plug a few more holes, as shown in the paper, and
>> offer "strict mode", where only the checkable forms are allowed,
>> encourage a move to 100% strict mode code in security-critical
>> applications, and, at last, no more buffer overflows.
>>
>>     If we can only fix the backwards compatibility problems
>> with VLAs...
> 
> Perhaps, as a mode of operation, you could just assume that VLA are
> part of the language :) And that actually what you are proposing would
> make them much more useful and widely adaptable?
> 
> A strict mode could require that the visible prototype for a function
> with VM types in the argument list (BTW they are never VLA themselves,
> but pointers to VLA) should have the same expression as the definition
> of the function, and that these expression should be such that their
> evaluation could already take place at the point of declaration
> without changing the value. Something like it should only contain
> 
> - other parameters already declared previously in the list
> - integer constant expressions that can be evaluated at declaration of
>   the first prototype
> - maybe also evaluations of global variables that are known at the
>   declaration of the first prototype, but I am less sure for this part
> 
> I would claim that this is good style for programming with VM, anyhow.
> But since all these requirements would be for strict mode only, so
> this wouldn't create incompatibilities with existing code.
> 
> Then all the computations for bounds could again be done at the
> calling side without changing the ABI, we still would only pass
> pointers around.
> 
> Jens
> 

    That's the general idea.  But it also has to work for
dynamically allocated arrays ("malloc") which means
the casting issues have to be worked through.  I've
struggled with this, and it can be made to work with
references.  With pointers alone, though, I haven't
been able to make the hard cases work.  More later.
I'm going out.

			John Nagle

[toc] | [prev] | [next] | [standalone]

#1495

Am 16.08.2012 01:32, schrieb John Nagle:
> On 8/15/2012 3:51 PM, Jens Gustedt wrote:
>> Perhaps, as a mode of operation, you could just assume that VLA are
>> part of the language :) And that actually what you are proposing would
>> make them much more useful and widely adaptable?
>>
>> A strict mode could require that the visible prototype for a function
>> with VM types in the argument list (BTW they are never VLA themselves,
>> but pointers to VLA) should have the same expression as the definition
>> of the function, and that these expression should be such that their
>> evaluation could already take place at the point of declaration
>> without changing the value. Something like it should only contain
>>
>> - other parameters already declared previously in the list
>> - integer constant expressions that can be evaluated at declaration of
>>   the first prototype
>> - maybe also evaluations of global variables that are known at the
>>   declaration of the first prototype, but I am less sure for this part
>>
>> I would claim that this is good style for programming with VM, anyhow.
>> But since all these requirements would be for strict mode only, so
>> this wouldn't create incompatibilities with existing code.
>>
>> Then all the computations for bounds could again be done at the
>> calling side without changing the ABI, we still would only pass
>> pointers around.
>>
>> Jens
>>
> 
>     That's the general idea.  But it also has to work for
> dynamically allocated arrays ("malloc") which means
> the casting issues have to be worked through.  I've
> struggled with this, and it can be made to work with
> references.  With pointers alone, though, I haven't
> been able to make the hard cases work.  More later.
> I'm going out.

No, please don't even try. The force of C is that its implicit type
conversions are such that explicit casts are rarely needed (if at all)
and are frowned upon by advanced programmers. Usually only beginners
feel the need of casting the return of malloc for example.

This should remain so if you want acceptance for your proposal in the
C community.

And you don't need it. You can do

double (*A)[n] = malloc(sizeof(double[n]));

and then use that pointer as

for (size_t i = 0; i < lengthof(*A); ++i) (*A)[i] = i;
free(A);

without any further changes. So all what we discussed applies. You can
use "strict mode" for that, check bounds, everything you want. No
additions needed, everything remains ABI compatible.

There are two points that I see that have to be cleared on such an
approach:

 - have an enhancement of malloc that verifies the initialization of
   the pointer

 - help the programmer use this interface through references

For the allocation this would need a new operator that wraps
malloc. Let's call it "alloc" for the moment (it shouldn't be called
"new" since the semantics would be different from C++).

 > alloc(type-name) shall allocate one object of type type-name and
 > return the address of that object as if a call to
 > malloc(sizeof(type-name)) was issued and the underlying object had
 > been default initialized. The type of an alloc expression is
 > unqualified pointer to type-name.

So then the above allocation would read

double (*A)[n] = alloc(double[n]);

and all size checks could be performed, here.

For the programming interface there would be the need for references
that you could argue here. People would hesitate to use these
interfaces because of the ugliness of (*A)[i]. If references would be
just a convenience to replace (*A) by an identifier, this ugliness
would just disappear.

This can almost be done by a macro. In the example above

#define B /*!!*/ (*A)

double B[n] = alloc(double[n]);
for (size_t i = 0; i < lengthof(B); ++i) B[i] = i;
free(&B);

which should look ok for every day programming (besides the macro, I
mean).

Now if you introduce reference to do exactly that, give some sugar to
make the (*A) expressions disappear, everybody could easily convinced
that they don't do harm to the language and are easily implemented.

So to summarize, what you need for now to implement a "strict mode"

 - additional constraints about the consistency between function
   prototypes
 - a new "alloc" operator that returns a properly typed pointer
 - references to make the programming in that model bearable

Another point that should be discussed is how a linker is supposed to
check that two different compilation units that are compiled in strict
mode are linked together, such that it can be guaranteed that they are
using strictly (!) the same declarations. But this should be possible
by adding some additional symbol for each function that has a suitably
mangle name.

PS: I haven't seen anything about default initialization in your
proposal. I think it would be a good thing to constrain all variables
to be initialized in strict mode.

Jens

[toc] | [prev] | [next] | [standalone]

#1492

Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 15.08.2012 21:50, schrieb Keith Thompson:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> [...]
>>> Do you think that implementing a bound check with the [static]
>>> interface for function parameters would be easy to do?
>> [...]
>
> snip
>
>> I suppose you could pass implicit bounds parameters, and set them to
>> some distinguished "unknown" value when the bounds aren't available.
>> But then you have incomplete bounds checking, and it can be difficult
>> for the programmer to know when the bounds are actually checked.
>> 
>> And what happens if a bound check fails?
>> 
>> Or perhaps there's some elegant solution that I'm missing.
>
> I think you are missing that the bounds checking can be done at the
> calling side. The calling side has seen the interface of the function
> and knows of the restriction.
>
> It is not perfect and would not easily work with plain pointers that
> are passed as arguments, but it could be implement without any
> additional data if arrays are passed.

That helps, but there are still cases where checking isn't going to be
possible, and I think it's going to be difficult for programmers to know
when checking is possible and when it isn't (and to define when it is or
isn't required).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1493

On 8/15/2012 5:22 PM, Keith Thompson wrote:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> Am 15.08.2012 21:50, schrieb Keith Thompson:
>>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>>> [...]
>>>> Do you think that implementing a bound check with the [static]
>>>> interface for function parameters would be easy to do?
>>> [...]
or the programmer to know when the bounds are actually checked.
>>>
>>> And what happens if a bound check fails?

    Action will be taken per Annex K.  A programmer-defined
error function will be called.  The options at that point
are limited, but there's at least the option to do some
closeout or restart work and exit.

>>> Or perhaps there's some elegant solution that I'm missing.
>>
>> I think you are missing that the bounds checking can be done at the
>> calling side. The calling side has seen the interface of the function
>> and knows of the restriction.
>>
>> It is not perfect and would not easily work with plain pointers that
>> are passed as arguments, but it could be implement without any
>> additional data if arrays are passed.
> 
> That helps, but there are still cases where checking isn't going to be
> possible, and I think it's going to be difficult for programmers to know
> when checking is possible and when it isn't (and to define when it is or
> isn't required).

   That's what the "strict mode" proposal is about.  It disallows the
cases where checking isn't possible.  Strict and non-strict translation
units can call each other.  If all translation units are strict,
everything is checkable.  This provides a migration path.

   Libraries can be made strict yet still be called from non-strict
code.  That's important for compatibility.

   There's a big payoff here if this can be brought off.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1479

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The most recent draft of the C+++ standard that I have is n3035.pdf,
> which is fairly old (2010-02-16),
[...]

<OT>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
is newer; I understand it's very close to the released C++ 2011
standard.
</OT>

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1482

On 08/15/2012 03:36 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> The most recent draft of the C+++ standard that I have is n3035.pdf,
>> which is fairly old (2010-02-16),
> [...]
> 
> <OT>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf
> is newer; I understand it's very close to the released C++ 2011
> standard.
> </OT>

Thanks. I've recently acquired new responsibilities (without, of course,
losing any of my old responsibilities) that include working on C++ code,
so I'm finally going to put some of my C++ knowledge to work. However,
in the words of the guy I'm replacing, the policy on my new project
seems to be

> ... we use version C++"it compiles on our 
> machines and everyone else's, and we all try to use the same version of 
> the same compiler, so nobody cares if the code uses an extension that's 
> not quite part of the C++ standard".

So an up-to-date version of the C++ standard might turn out less useful
than a document that describes the latest version of GnuC++. :-(

The code I've newly become responsible for makes extensive use of all of
the following constructs:

	#define _Reserved_Name_
	#include <non-standard-header.h>
	    return (expression);
	    double d = (double)expression;

Sigh. It could have been (a lot!) worse.

[toc] | [prev] | [next] | [standalone]

#1463

Am 15.08.2012 00:58, schrieb James Kuyper:
> On 08/14/2012 06:35 PM, John Nagle wrote:
>> What's the use case for that, anyway?
> 
> It's nothing more or less than an alternative way of saying "double
> *const arr" in a function parameter declaration. Arguably, we don't need
> another way of saying "double *const arr", but that same argument
> applies to using "double arr[100]" as an alternative way of saying
> "double *arr". Declaring a pointer as if it were an array remains
> popular, and as long as that's the case, providing a way to insert a
> qualifier so that it applies to the pointer itself, rather than the
> thing it points at, makes that alternative a little more convenient.

This feature was introduced with the [static ] concept in this context.

double a[static 100]

is a declaration of a pointer parameter

double * a

that in addition has the sematic to point to an array object of at
least 100 elements. This is not expressible with a

double * a

interface specification, alone. Now if you have that you also want the
possibility to express the property that the pointer (itself) is
qualified. Thus

double a[static const 100]

is equivalent with an interface having

double *const a

and the additional constraint on the size of the object that is
pointed to.

As the discussion here proves this feature is not well known, and most
compilers just implement it by silently ignoring the "static".

So we have an interface that could be used to do at least a
rudimentary bound checking, but nobody uses it.

My guess would be that checking this with non-VLA should be easy at
compile time since the expression that is allowed (here the "100")
must be a constant integer expression. To my knowledge nobody does
that yet, but it would be a good point to start. (We have a compiler
writer participating in this discussion, so go ahead give it a try.)

Checking this with a VLA that is passed as a parameter would be a
runtime check, so it probably needs a bit more effort to
implement. But the "bounds checking interfaces" could probably be a
starting point of doing these things.

Jens

[toc] | [prev] | [next] | [standalone]

#1451

John Nagle <nagle@animats.com> writes:
> On 8/14/2012 2:59 PM, Keith Thompson wrote:
[...]
>> There are no qualifiers in this example.
>
>     Oh, I see.  Qualifiers are allowed inside size declarations.
> This is valid:
>
> 	double arr[const 100];
>
> What's the use case for that, anyway?

The 100 is silently ignored, and the "const" causes arr to be a
pointer to const double.  It means that if you pass (the address of
the first element of) an array to the function, the function can't
modify the elements of that array (unless it casts away the "const").
This can allow the compiler to perform some additional optimizations.

IMHO it would be clearer to define that parameter as:

    const double *arr

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1452

Keith Thompson <kst-u@mib.org> writes:
> John Nagle <nagle@animats.com> writes:
>> On 8/14/2012 2:59 PM, Keith Thompson wrote:
> [...]
>>> There are no qualifiers in this example.
>>
>>     Oh, I see.  Qualifiers are allowed inside size declarations.
>> This is valid:
>>
>> 	double arr[const 100];
>>
>> What's the use case for that, anyway?
>
> The 100 is silently ignored, and the "const" causes arr to be a
> pointer to const double.  It means that if you pass (the address of
> the first element of) an array to the function, the function can't
> modify the elements of that array (unless it casts away the "const").
> This can allow the compiler to perform some additional optimizations.
>
> IMHO it would be clearer to define that parameter as:
>
>     const double *arr

My apologies, I got that backwards.  The "const" applies to the
pointer type, not to what it points to.

So a parameter definition "double arr[const 100]" means the same
thing as "double *const arr" (IMHO the latter is clearer).

Defining a parameter as "const" has no effect on the caller; it
just means that the function itself cannot modify the value of the
parameter (which is a local object).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1456

Le 15/08/12 01:38, Keith Thompson a écrit :
> Keith Thompson <kst-u@mib.org> writes:
>> John Nagle <nagle@animats.com> writes:
>>> On 8/14/2012 2:59 PM, Keith Thompson wrote:
>> [...]
>>>> There are no qualifiers in this example.
>>>
>>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>>> This is valid:
>>>
>>> 	double arr[const 100];
>>>
>>> What's the use case for that, anyway?
>>
>> The 100 is silently ignored, and the "const" causes arr to be a
>> pointer to const double.  It means that if you pass (the address of
>> the first element of) an array to the function, the function can't
>> modify the elements of that array (unless it casts away the "const").
>> This can allow the compiler to perform some additional optimizations.
>>
>> IMHO it would be clearer to define that parameter as:
>>
>>      const double *arr
>
> My apologies, I got that backwards.  The "const" applies to the
> pointer type, not to what it points to.
>
> So a parameter definition "double arr[const 100]" means the same
> thing as "double *const arr" (IMHO the latter is clearer).
>
> Defining a parameter as "const" has no effect on the caller; it
> just means that the function itself cannot modify the value of the
> parameter (which is a local object).
>

You are wrong. See my answer to the other posters that posted the same 
nonsense

[toc] | [prev] | [next] | [standalone]

#1457

jacob navia <jacob@spamsink.net> writes:
> Le 15/08/12 01:38, Keith Thompson a écrit :
>> Keith Thompson <kst-u@mib.org> writes:
>>> John Nagle <nagle@animats.com> writes:
>>>> On 8/14/2012 2:59 PM, Keith Thompson wrote:
>>> [...]
>>>>> There are no qualifiers in this example.
>>>>
>>>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>>>> This is valid:
>>>>
>>>> 	double arr[const 100];
>>>>
>>>> What's the use case for that, anyway?
>>>
>>> The 100 is silently ignored, and the "const" causes arr to be a
>>> pointer to const double.  It means that if you pass (the address of
>>> the first element of) an array to the function, the function can't
>>> modify the elements of that array (unless it casts away the "const").
>>> This can allow the compiler to perform some additional optimizations.
>>>
>>> IMHO it would be clearer to define that parameter as:
>>>
>>>      const double *arr
>>
>> My apologies, I got that backwards.  The "const" applies to the
>> pointer type, not to what it points to.
>>
>> So a parameter definition "double arr[const 100]" means the same
>> thing as "double *const arr" (IMHO the latter is clearer).
>>
>> Defining a parameter as "const" has no effect on the caller; it
>> just means that the function itself cannot modify the value of the
>> parameter (which is a local object).
>
> You are wrong. See my answer to the other posters that posted the same
> nonsense

I believe you're thinking of "static", not "const".

This (as a parameter declaration):

    double arr[static 100]

asserts that arr points to the first element of an array of at least 100
elements.  This is stated as a "shall" outside any constraint, meaning
that if the actual parameter points to the beginning of an array with
fewer than 100 elements, the behavior is undefined.

On the other hand, this:

    double arr[const 100]

is equivalent to

    double *const arr

(with the 100 silently ignored).

See N1370 6.7.6.3p7.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1462

Am 15.08.2012 06:46, schrieb jacob navia:

> You are wrong. See my answer to the other posters that posted the same
> nonsense

Jacob, these types of remarks are not very constructive, if, as in this
case you are completely off the track. Perhaps check the standard before
insulting people?

Jens

[toc] | [prev] | [next] | [standalone]

#1464

Le 15/08/12 08:34, Jens Gustedt a écrit :
> Am 15.08.2012 06:46, schrieb jacob navia:
>
>> You are wrong. See my answer to the other posters that posted the same
>> nonsense
>
> Jacob, these types of remarks are not very constructive, if, as in this
> case you are completely off the track. Perhaps check the standard before
> insulting people?
>
> Jens
>

Yes, it was me talking nonsense.

As you can see, it happens :-(

[toc] | [prev] | [next] | [standalone]

#1507

On 8/14/2012 11:20 AM, John Nagle wrote:
> On 8/13/2012 10:23 PM, Keith Thompson wrote:
>> John Nagle <nagle@animats.com> writes:
>>> On 8/13/2012 2:23 PM, Jens Gustedt wrote:
>> [...]

>> C does not have parameters of array type.  "a" is not an array, it's a
>> pointer.  The array isn't passed "by reference" in the C++ sense; rather
>> a pointer to the first element of the array is passed.
>>
>> N1570 6.7.6.3p7:
>>
>>     A declaration of a parameter as "array of _type_" shall be adjusted
>>     to "qualified pointer to _type_", where the type qualifiers
>>     (if any) are those specified within the [ and ] of the array
>>     type derivation.

   This raises an interesting question.  Suppose VLA parameters were
treated as arrays in the called function, with the same semantics
as a local array.  What would change?  What would this break?

    subscripting - no change
	
    passing to another function expecting an array parameter
      - no change, and size-checkable.

    passing to another function expecting a pointer - no change,
      conversion to a pointer of the appropriate type would result.

    assignment to a pointer - no change, conversion to
       a pointer of the appropriate type.

    sizeof - would change, but if someone used sizeof on a VLA
       parameter, they probably got an answer (the constant size of
       a pointer) they didn't expect.  If we ever find an instance
       of that in production code, it will probably turn out to be
       a bug.

   One could perhaps think of this as deferring the "adjustment to
a qualified pointer to "_type_" until conversion to a pointer
is unavoidable.   Maybe this isn't that big a deal to fix.

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1508

On 16-Aug-12 4:09 PM, John Nagle wrote:
>     This raises an interesting question.  Suppose VLA parameters were
> treated as arrays in the called function, with the same semantics
> as a local array.  What would change?  What would this break?

Off the top of my head:


Functions declared using one syntax, and then again using the other:

   int foo( int n, double arr[n] ); // Prototype in a header
   int foo( int n, double *ptr ) { ... // Implementation


Code that walks the array using the pointer:

   int foo( int n, double x[n] ) {
     while ( n > 0 && *x++ < 0 ) --n;
     return n;
   }


Code that takes the address of the pointer:

   int foo( int n, double x[n] ) {
     double **ptr = &x;
     ...
   }

[toc] | [prev] | [next] | [standalone]

#1509

On 8/16/2012 1:21 PM, Wojtek Lerch wrote:
> On 16-Aug-12 4:09 PM, John Nagle wrote:
>>     This raises an interesting question.  Suppose VLA parameters were
>> treated as arrays in the called function, with the same semantics
>> as a local array.  What would change?  What would this break?
> 
> Off the top of my head:
> 
> 
> Functions declared using one syntax, and then again using the other:
> 
>   int foo( int n, double arr[n] ); // Prototype in a header
>   int foo( int n, double *ptr ) { ... // Implementation
> 
> 
> Code that walks the array using the pointer:
> 
>   int foo( int n, double x[n] ) {
>     while ( n > 0 && *x++ < 0 ) --n;
>     return n;
>   }

   That might actually be useful.  It's not a pointer/array
issue, though.  It's an lvalue issue.

   This would generate a compile-time error if x were
treated as an array, so it could not produce invisible
changes in behavior.

> Code that takes the address of the pointer:
> 
>   int foo( int n, double x[n] ) {
>     double **ptr = &x;
>     ...
>   }

    Not too useful in practice.  What's actually passed to
the function is a pointer to the array.  So the address of a
pointer is actually the address of a temporary copy of the
pointer passed to the function.  On machines with register-based
calling sequences (remember SPARC machines?), a conforming
implementation would have to create a temporary just to have
something addressable.  The use cases for this are limited.

   As above, this would generate a compile-time error.

   This is encouraging.  Anything else?

				John Nagle

[toc] | [prev] | [next] | [standalone]

#1510

John Nagle <nagle@animats.com> writes:
> On 8/16/2012 1:21 PM, Wojtek Lerch wrote:
[...]
>> Code that takes the address of the pointer:
>> 
>>   int foo( int n, double x[n] ) {
>>     double **ptr = &x;
>>     ...
>>   }
>
>     Not too useful in practice.  What's actually passed to
> the function is a pointer to the array.

No, it's a pointer to the first element of the array.  x is of type
double*, not double (*)[n].

>                                          So the address of a
> pointer is actually the address of a temporary copy of the
> pointer passed to the function.  On machines with register-based
> calling sequences (remember SPARC machines?), a conforming
> implementation would have to create a temporary just to have
> something addressable.

It's no more a "temporary" than any other parameter.  Like any
parameter, it's an object with automatic storage duration whose lifetime
extends across the execution of the function, and there's nothing
unusual about taking its address.

>                         The use cases for this are limited.

Suppose you want to call a function that updates a pointer object:

    void update(double **ptr);
    ...
    update(&x);

Since x is merely a local object, there's nothing invalid about doing
this.  It could be argued that modifying a parameter is poor style, but
C specifically allows it.

>    As above, this would generate a compile-time error.

Which could break existing code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#1512

On 16/08/2012 5:22 PM, John Nagle wrote:
> On 8/16/2012 1:21 PM, Wojtek Lerch wrote:
>> On 16-Aug-12 4:09 PM, John Nagle wrote:
>>>      This raises an interesting question.  Suppose VLA parameters were
>>> treated as arrays in the called function, with the same semantics
>>> as a local array.  What would change?  What would this break?
...
>> Code that walks the array using the pointer:
>>
>>    int foo( int n, double x[n] ) {
>>      while ( n > 0 && *x++ < 0 ) --n;
>>      return n;
>>    }
>
>     That might actually be useful.

Yes, I've used it.  And I wouldn't like it if you broke it.  It would be 
easy to fix, but I still don't like the idea of having to fix it.

>       It's not a pointer/array
> issue, though.  It's an lvalue issue.

Whatever you call it, the issue is that today it's a local pointer 
variable that I'm free to increment, assign a NULL to, or do anything 
else I can do with a local pointer variable, and you want to turn it 
into an array and make all those things invalid.

>     This would generate a compile-time error if x were
> treated as an array, so it could not produce invisible
> changes in behavior.

I know, but you asked what it would break, not what it would silently 
change.  A compiler error counts as a breakage to me.

>> Code that takes the address of the pointer:
>>
>>    int foo( int n, double x[n] ) {
>>      double **ptr = &x;
>>      ...
>>    }
>
>      Not too useful in practice.  What's actually passed to
> the function is a pointer to the array.

No, it's a pointer to a double.  The double could be an element of an 
array (not necessarily the first element!) or just a simple double 
variable.  The value I pass for n doesn't have to have anything with 
what x points to -- it can very well be negative.

>   So the address of a
> pointer is actually the address of a temporary copy of the
> pointer passed to the function.  On machines with register-based
> calling sequences (remember SPARC machines?), a conforming
> implementation would have to create a temporary just to have
> something addressable.  The use cases for this are limited.

It isn't any more temporary than any other automatic variable.  If I 
take its address, of course the compiler must make it addressable 
(unless the optimizer finds a way not to).  It's not completely uncommon 
to use pointers to pointers, perhaps for the purpose of giving them to a 
function that take the value of our x and replace it with some other 
value.  Your proposed change would force me to introduce an extra 
pointer variable for this purpose, which, again, is not a huge change, 
especially in simple cases like this example, but for sure it would be 
annoying.

     int foo( int n, double x[n] ) {
       double *y = x;
       double **ptr = &y;
       ...

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.std.c

csiph-web