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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#1422

Hello,

Am 14.08.2012 05:08, schrieb John Nagle:
> On 8/13/2012 2:23 PM, Jens Gustedt wrote:

>>  > Relaxation of existing restrictions
>>  > • Expressions allowed in most array size declarations. (This is the
>>  > key enhancement.)
>>
>> I don't see how this is new to C. If you mean you want to extend the
>> idea of VLA to file scope, I'd first like to have a reasonable
>> semantic for this. (When will the corresponding size expressions be
>> evaluated?)
> 
>     See page 8, "Array size expressions": "the array size
> expressions evaluated where a function is called must produce the
> same results when recomputed inside the function when the function
> is entered."  The key concept here is that array size expressions
> are computable using only constants and function parameters
> (or structure elements, for structures).

So this then would restrict existing use patterns? Currently the
evaluation of array sizes at the side of the definition allows
arbitrary expressions. It seems that you want to restrict that? You'd
have to collect strong arguments to convince people that existing
conforming programs will become invalid.

>>
>>  > Features imported from C++11
>>  > • auto
>>
>> Things like this doesn't happen as quickly to C as to C++.
> 
>     See previous message by Keith Thompson, who addresses this
> in some detail.

I know all the details of that and what the auto feature implies. This
has been discussed before. And I am not objecting the feature itself
(though I would have prefered the gcc typeof extesion) but its
syntax. There is no reason that they couldn't have chosen another
keyword for this. C is not here to clean up the mess that C++
produces. So if this happens this should be with a different keyword,
perhaps _Auto or so, but not auto.

>>  > • References
>>
>> why not? but it is unlikely that such a thing will enter C through the
>> backdoor of array handling. This would need a very detailed analysis
>> and proposal of its own, which should be treated as separate issue.
> 
>     C++ references seem to play well with C semantics.  If there were
> problems in that area, they would have been discovered a decade or two
> ago.

This also has been discussed several times. So far it seems that the
committee was never sufficiently motivated to include them. Easing the
handling of VLA could be a strong argument for that, if you elaborate
that correctly and precisely.

>>  > New reserved words
>>  > • force_cast (storage class, for casts only, allows forcing certain
>> casts in strict mode)
>>
>> different types of cast as they are in C++?
> 
>     force_cast is really reinterpret_cast of C++, but the corner-bracket
> syntax used in C++ isn't allowed in C.  Hence the problem.
> The general idea is that, in strict mode (see the paper) C casts
> are restricted to memory-safe operations.  force_cast is for the
> rare occasions it is necessary to override that.
>>
>>  > • void_space (type, for arrays of memory with unspecified contents)
>>
>> there is simply no need for this since C already has such a data
>> type. It is call unsigned char.
> 
>     If that were correct, the POSIX declaration of "read" would not
> be
> 
> 	ssize_t read(int fd, void *buf, size_t count);
> 
> But it is.

Please don't start distracting us with interfaces that are defined
beyond the scope of the C standard.

> "void *" was introduced to avoid type conversion problems when going
> from uninterpreted bits to a defined type.  But "void *" has no size.
> We want to have sized arrays of uninterpreted bytes, which can
> be converted to and from other types without casting, as with void*,
> provided that the sizes match and the type does not contain pointers
> or references.

I don't see why unsigned char can't serve as such. Or are you just
after the gcc extension of allowing pointer arithmetic for void* ?

>>
>>  > New predefined functions
>>  > • size_t lengthof(array);
>>
>> ok
> 
>    As someone else pointed out, "sizeof" is really an operator, so
> "lengthof" should be one as well.

It could be defined in the same vein as the offsetof macro, only that
there really is no need to standardize this. Anybody can write this
immediately as

#define lengthof(A) ((sizeof A)/(sizeof A[0]))


>> void copybyref(size_t n, int (&a)[n], const int (&b)[n])
> 
>    There's much legacy code, including POSIX, Linux, and
> C library APIs in which the size is given last.  It's an old
> tradition in C.  Breaking that would have substantial impact.
> 
>    GCC already offers a feature like this as an extension.
> See
> 
> http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable-Length
> 
>   GCC gets around this problem by allowing forward declarations
> in parameter lists.  In GCC, the above would be written:
> 
>    void copybyref(size_t n; int (&a)[n], const int (&b)[n], size_t n)
> 
> where "size_t n;" is a forward declaration, not a parameter.
> What's thinking on this?  Is it better to have forward declarations
> of formal parameters, or to handle array size expressions as a
> special, limited form of expression?

I personally don't like this gcc extension, prototypes quickly become
difficult to read.

>> But this already shows that the advantage you are trying to advertise
>> is minimal. In existing C such an interface could look
>>
>> void copybyref(size_t n, int (*a)[n], const int (*b)[n])
>>
>> which is a legal way to lift the array dimensions to the
>> function.
> 
>    C99 lets you go further than that. See ISO/IEC 9899:TC2, Example 4,
> page 133:
> (page ref to: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)

snip

> That code is passing an array by reference, even though
> C99 doesn't use that term.  So C99 already has much of
> what I'm proposing.

exactly, and BTW the current standard is C11, if would be good if you
use this as your main reference.

>  This is an obscure feature, one
> I hadn't known about. 

I don't think that it is obscure. That you hadn't know about it
doesn't make it so.

> It doesn't seem to be used,
> or even mentioned, much.  This is not allowed in C++.

C++ doesn't have VLA in the first place, so sure it can't have it.

> In GCC, applying "sizeof" to the array a above returns 4,
> That's probably wrong, per 6.3.5.4, para. 2:
> "If the type of the operand is a variable length array
> type, the operand is evaluated".  "sizeof" in C99 is
> supposed to be able to access the size of variable length
> arrays.

This already has been explained else-thread. And again update your
reference to C11, C99 is the past.

> The hard parts of what I'm proposing seem to be already in C99.
> But some of the supporting features needed to make them useful
> is missing.

some maybe. reference could be a nice feature in that context. On the
other hand references for VLA are probably the difficult part of
implementing these.

Jens

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

#1423

On 08/13/2012 11:08 PM, John Nagle wrote:
> On 8/13/2012 2:23 PM, Jens Gustedt wrote:
...
>>  > Relaxation of existing restrictions
>>  > � Expressions allowed in most array size declarations. (This is the
>>  > key enhancement.)
>>
>> I don't see how this is new to C. If you mean you want to extend the
>> idea of VLA to file scope, I'd first like to have a reasonable
>> semantic for this. (When will the corresponding size expressions be
>> evaluated?)
> 
>     See page 8, "Array size expressions": "the array size
> expressions evaluated where a function is called must produce the
> same results when recomputed inside the function when the function
> is entered."  The key concept here is that array size expressions
> are computable using only constants and function parameters
> (or structure elements, for structures).

You described this as a "relaxation of existing restrictions", but
you're imposing restrictions that don't currently exist: that the array
size expressions be computable using only constants and function parameters.

...
>>  > � References
>>
>> why not? but it is unlikely that such a thing will enter C through the
>> backdoor of array handling. This would need a very detailed analysis
>> and proposal of its own, which should be treated as separate issue.
> 
>     C++ references seem to play well with C semantics.  If there were
> problems in that area, they would have been discovered a decade or two
> ago.

It WAS discovered a decade or two ago. First Stroustrup, and later the
C++ committee, had to write lots of special rules addressing references,
in order to make them work with C-like semantics. Unfortunately, the
special rules in C would have to be a bit different, the C committee
cannot copy over the work that the C++ committee did.

>>  > New reserved words
>>  > � force_cast (storage class, for casts only, allows forcing certain
>> casts in strict mode)
>>
>> different types of cast as they are in C++?
> 
>     force_cast is really reinterpret_cast of C++, but the corner-bracket
> syntax used in C++ isn't allowed in C.

I don't see that as an issue; the angle bracket notation was introduced
in C++ to distinguish the type parameter of reinterpret_cast from the
value parameter. If you're going to add something like that in C,
there's no particular reason why you couldn't use angle brackets for
them. You'll have to address the potential for syntactic confusion with
the "<" and ">" operators, but that's not particularly difficult. If
it's really an adaptation of reinterpret_cast<>, it should be given the
same name. Otherwise it's a gratuitous discrepancy between C and C++,
something both committees have agreed to avoid.
-- 
James Kuyper

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

#1424

Am 14.08.2012 12:18, schrieb James Kuyper:
> On 08/13/2012 11:08 PM, John Nagle wrote:
>>     force_cast is really reinterpret_cast of C++, but the corner-bracket
>> syntax used in C++ isn't allowed in C.
> 
> I don't see that as an issue; the angle bracket notation was introduced
> in C++ to distinguish the type parameter of reinterpret_cast from the
> value parameter. If you're going to add something like that in C,
> there's no particular reason why you couldn't use angle brackets for
> them. You'll have to address the potential for syntactic confusion with
> the "<" and ">" operators, but that's not particularly difficult. If
> it's really an adaptation of reinterpret_cast<>, it should be given the
> same name. Otherwise it's a gratuitous discrepancy between C and C++,
> something both committees have agreed to avoid.

Import the crude syntax of < > brackets to C? I suppose you are aware
all the implications on the syntax. E.g that nesting such constructs
could clash into a shift operator, and that these guys are not
parenthesis for the preprocessor?

But perhaps before going on syntax, I think the semantics of such a
thing are not quite delivered yet.

If bound-checking (or more generally bound enforcement) is really the
primary goal of this proposal, perhaps John could elaborate more
precisely on his strict mode. Preferably by trying to argue inside the
current C standard, and how this would impact VLA, or more generally
VM types. My guess that all this could be done without all the sugar
of references, auto-types and stuff like that.

John, I also wonder if you are aware that the current standard has a
normative annex K that is called "Bounds-checking interfaces". This is
mostly about replacing library functions, but it also introduces the
interesting concept of "Runtime-constraint violations".

Jens

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

#1426

On 8/14/2012 3:42 AM, Jens Gustedt wrote:
> Am 14.08.2012 12:18, schrieb James Kuyper:
>> On 08/13/2012 11:08 PM, John Nagle wrote:

> If bound-checking (or more generally bound enforcement) is really the
> primary goal of this proposal, perhaps John could elaborate more
> precisely on his strict mode. Preferably by trying to argue inside the
> current C standard, and how this would impact VLA, or more generally
> VM types. My guess that all this could be done without all the sugar
> of references, auto-types and stuff like that.

    OK, let's see what you can come up with.  It's a well known problem,
So far, everyone who has tried has ended up with a new, incompatible
language, such as Cyclone, or had to carry extensive additional
run-time data with every pointer, such as CCured or Safe C.

> John, I also wonder if you are aware that the current standard has a
> normative annex K that is called "Bounds-checking interfaces". This is
> mostly about replacing library functions, but it also introduces the
> interesting concept of "Runtime-constraint violations".

    I knew about that.  At least we have a defined action to take
when trouble is detected, and "set_constraint_handler_s" to set
that action.   I'' reference that in future revisions.

				John Nagle

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

#1427

On 14.08.2012 18:43, John Nagle wrote:

>      OK, let's see what you can come up with.  It's a well known problem,
> So far, everyone who has tried has ended up with a new, incompatible
> language, such as Cyclone, or had to carry extensive additional
> run-time data with every pointer, such as CCured or Safe C.

And is it really so inconceivable that this might be because the problem 
actually is _impossible_ to solve without going to such extreme 
measures?  The capability to have buffer overflows is built all the way 
down into the foundations of this language.  There's no taking that out 
without upending the whole building.

Among programming languages in use today, C is most often analogized to 
a scalpel, largely because of the skill and discipline it takes to wield 
it safely --- and the hurtful consequences of lacking that skill or 
discipline.  Within that analogy, you've observed that several teams 
have tried to make a safer scalpel, but all they ended up with was yet 
another type of safety razor.  Now if all you wanted to do with that 
scalpel in the first place was to shave, then a safety razor would 
undoubtedly qualify as a great achievement.  But it doesn't make scalpel 
use in the science lab or surgical operating room one bit safer, because 
a safety razor simply can't do the job there.

 From what I'm seeing in here, it looks like the primary difference 
between your proposed safety razor called "strict mode C" and the 
earlier models is that there's still going to be an actual scalpel in 
there, too, plus a switch to decide whether the thing transforms itself 
into a scalpel or a safety razor.  That strikes me as being worse than 
both the original devices --- it would be just too unsafe to be a proper 
safety razor, and too unwieldy to make a proper scalpel.

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

#1431

Le 14/08/12 19:52, Hans-Bernhard Bröker a écrit :
> And is it really so inconceivable that this might be because the problem
> actually is _impossible_ to solve without going to such extreme
> measures?  The capability to have buffer overflows is built all the way
> down into the foundations of this language.  There's no taking that out
> without upending the whole building.

There is an OBVIOUS way: operator overloading, as I have been arguing
since 10 years.

See my other post in this same thread.

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

#1435

Am 14.08.2012 18:43, schrieb John Nagle:
>     OK, let's see what you can come up with.  It's a well known problem,
> So far, everyone who has tried has ended up with a new, incompatible
> language, such as Cyclone, or had to carry extensive additional
> run-time data with every pointer, such as CCured or Safe C.

There is certainly a potential for improvement in C where it allows to
assign pointers to differently sized VLA, considering them to be
compatible.

Here, at runtime, the information is available if the sizes fit, so it
should not be too difficult to implement a runtime check for this and
to throw some sort of runtime constraint violation. If you would
formalize that with a "strict" approach it could be a good start.

If in such a strict setting one still would do such an assignement,
one could easily cast this pointer through void* to rip off all type
(and size) information. So I don't think there would even be a need
for a new cast operator in C.

The runtime expenses for such a check would be moderate, since the
size information for the pointed-to-VLA is present at the place where
it is needed. In particular other pointers (not to VLA) would not be
affected.

Jens

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

#1425

On 8/13/2012 11:08 PM, John Nagle wrote:
>
>      As the introduction to the paper says, "In any useful program,
> each array has a size known to the programmer. In C, there is
> currently no way to consistently express that size in the language.
> [...]

     This may be the most glaring example of the paper's careless
tendency to confuse "array" with "pointer."  It seems to me the
paper could do with a careful re-working to tighten up sloppy
language.

     For the record: Every (complete) array in a C program has a
size known to the programmer, expressed in the language, known to
the compiler, and derivable from its sizeof.  As written, the
introduction's statement is simply false.

     Given a pointer value, it is true that C offers almost no way
(but see 6.7.6.3p7) to express or derive the extent of an array
containing the pointer's target.  That's not a problem with the
array itself, but with the pointer.  That is, perhaps, why the
paper is mostly about substituting references for pointers, and
only peripherally concerned with the arrays.

     It seems to me the paper would benefit from a tightening of
terminology.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#1417

John Nagle <nagle@animats.com> writes:

> C already allows arrays of fixed size as formal parameters.
> C99 allows arrays of variable size as local variables.
> C++ allows references.
> If we combine those concepts, we can add to the language
> arrays of known size as formal parameters, with a size based
> on other formal parameters.  Like this:
>
> 	int read(int fd, char(&)buf[n], size_t n);
>
> This is not new syntax; that's how a reference to an array is
> passed in C++.

Surely you mean

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

?

-- 
Ben.

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

#1419

On 8/13/2012 2:44 PM, Ben Bacarisse wrote:
> John Nagle <nagle@animats.com> writes:
> 
>> C already allows arrays of fixed size as formal parameters.
>> C99 allows arrays of variable size as local variables.
>> C++ allows references.
>> If we combine those concepts, we can add to the language
>> arrays of known size as formal parameters, with a size based
>> on other formal parameters.  Like this:
>>
>> 	int read(int fd, char(&)buf[n], size_t n);
>>
>> This is not new syntax; that's how a reference to an array is
>> passed in C++.
> 
> Surely you mean
> 
>  	int read(int fd, char (&buf)[n], size_t n);

   Right. Sorry about that.

				John Nagle

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

#1430

Le 13/08/12 20:39, John Nagle a écrit :
> We are circulating an early draft proposal for an extension to C
> which offers a way to prevent most buffer overflows while retaining
> backwards compatibility with old code.  This has been discussed
> on some programming language forums (LtU) and updated to reflect
> criticisms and comments, and now we're exposing it to a wider
> community.
>
> This is not the first attempt to address this problem.  We know about
> most of the others, from SAL to Cyclone.  This one appears
> to have backwards compatibility good enough to be a potential candidate
> for inclusion in a future version of the C standard.
>
> Comments are requested.
>
> Abstract:
>
> Buffer overflows continue to plague C programs. This is a draft proposal
> for dealing with that problem. The basis of this proposal is to define
> means for expressing the size of arrays in C. C already has fixed-size
> arrays with useful semantics. In this proposal, the existing syntax for
> fixed-size arrays is generalized to allow known-size arrays, where the
> size of the array is known at variable initialization time. With
> relatively minor and compatible changes to C, the most troublesome
> causes of program crashes and security vulnerabilities can be dealt with.
>
> The short intro:
>
> C already allows arrays of fixed size as formal parameters.
> C99 allows arrays of variable size as local variables.
> C++ allows references.
> If we combine those concepts, we can add to the language
> arrays of known size as formal parameters, with a size based
> on other formal parameters.  Like this:
>
> 	int read(int fd, char(&)buf[n], size_t n);
>
> This is not new syntax; that's how a reference to an array is
> passed in C++. We're just allowing the size to be a variable.
> This leads to a backwards-compatible way to talk about and check
> array sizes.
>
> The paper:
> http://www.animats.com/papers/languages/safearraysforc36.pdf
>
> Please read this over and critique.  Thanks.
>
> 					John Nagle
> 					Animats
>

Have you ever considered what I am arguing since at least 10 years in 
this group:

To implement array checking the language should allow operator
overloading. Then, you could define your own class of arrays and
implement all the checks you want there.

This enhancement would also allow length checked strings, and many other
features that would make C a much safer language.

I have implemented this feature around 10 years ago in the lcc-win
compiler. Using this feature I implemented a whole replacement for the
string library where to port from old code to the "new" bound checking
code involved a replacement of "char *" by "String *".

I have presented this proposal several times in the last 10 years, but
it never got anywhere.

The problem is that your proposal is impossible to implement really. there
are SO MANY problems with C array handling that it is easier to just
do that for user defined array types that implement the indexing
operator THEMSELVES...

typedef struct tagIntArray
	size_t size;
	int *data;
} intArray;


int operator[](intArray a,int idx)
{
	if (idx < 0 || idx > a->size) {
		longjmp(recoveryBuffer,INDEX_ERROR);
	}
	return a->data[idx];
}

int operator[]=(intArray a,int idx,int newvalue)
{
	if (idx < 0 || idx > a->size) {
		longjmp(recoveryBuffer,INDEX_ERROR);
	}
	a->data[idx] = newvalue;
	return newvalue;
}

C++ went this way and it is obvious that is the easiest and safest way.
We can even do better than C++ that did not allow users to distinguish
between reading an array and assigning to it. Here we have TWO operators
for these two DIFFERENT operations.

Please consider that this is maybe a cleaner solution. The changes to 
the language are quite minimal.

Existing code remains 100% compatible.

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

#1442

jacob navia  wrote:

> C++ went this way and it is obvious that is the easiest and safest way.
> We can even do better than C++ that did not allow users to distinguish
> between reading an array and assigning to it. Here we have TWO operators
> for these two DIFFERENT operations.

In C++, you can return a proxy type, on which you are free to define
operator= as you like.

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

#1443

Le 14/08/12 23:18, Marc a écrit :
> jacob navia  wrote:
>
>> C++ went this way and it is obvious that is the easiest and safest way.
>> We can even do better than C++ that did not allow users to distinguish
>> between reading an array and assigning to it. Here we have TWO operators
>> for these two DIFFERENT operations.
>
> In C++, you can return a proxy type, on which you are free to define
> operator= as you like.
>

Sure, you need to define a proxy type and redefine yet another operator
to achieve the same thing as operator []=.

Why do things in a simple way
when you can make them more complex?

Why have one operator instead of two and a proxy?

:-)

If we have operator += why not []= ??

This allows to implement copy-on-write in a very simple way.

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

#1515

   OK, now that this has been discussed for a while, a recap
of what we've learned is in order.

- Variable length arrays were in the C99 standard, but implementation
  was not widespread.

- VLAs have been made an optional feature in the latest C
  standard draft.
  (Ref:  n1570.pdf: §6.7.6.2p4: "Variable length arrays are a
   conditional feature that implementations need not support")

- Microsoft explicitly declined to support VLAs as incompatible
  with C++.
  (ref:
http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/6099f453-db2c-49c3-b59a-b799c379cebb)

- VLA function parameters create problems with the C++ type model.
  C++ function overloading requires compile time matching of
  static types, and VLA parameters are incompatible with that
  model.  So importing the VLA feature into C++ appears unworkable.

- VLAs have been criticized on other grounds:
   - Some implementations of threads do not well accommodate
     large stack growth. This causes a problem when a large local
     VLA is allocated.
   - There is no way to recover from allocation failure of a VLA.
   - The behavior of "sizeof" for VLA function parameters differs from
        behavior on local VLAs.
   - Usage of VLA function parameters in actual code is rare.
   - Allowing an arbitrary expression as the size of a VLA function
     parameter means that the expression cannot be in general be
     evaluated in the context of the call.  So, for some expressions,
     call checking is not possible.

So, with C99 VLAs on the way out, it's appropriate to propose
alternatives.  Any alternative should potentially be portable
to C++.

My original proposal seems to fulfill that criterion.  It
starts with importing C++ references into C, and then
extends parameter syntax to support variable length
arrays in reference parameters.

Take a look at this again on that basis, please.

http://www.animats.com/papers/languages/safearraysforc36.pdf

				John Nagle

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

#1516

Hello,

Am 17.08.2012 18:40, schrieb John Nagle:
> So, with C99 VLAs on the way out, it's appropriate to propose
> alternatives.  Any alternative should potentially be portable
> to C++.

I think you completely misunderstand the situation. That the C11
standard makes VLA optional doesn't mean that they are phased
out. They are optional like other parts of the language, e.g _Complex,
_Atomic, thread support or the [u]intptr_t.

Many (most?) C compilers have VLA and will continue to have
them. Making proposals than are not compatible with existing parts of
the language, even if they are optional, will almost certainly be
rejected very quickly. For the simple reason that the committee will
not want to have contradicting parts inside the same standard, even if
they are optional.

> My original proposal seems to fulfill that criterion.  It
> starts with importing C++ references into C, and then
> extends parameter syntax to support variable length
> arrays in reference parameters.
> 
> Take a look at this again on that basis, please.

Perhaps *you* should take a look again on what I developped at some
point? I had the impression that there could be a path that could well
reconcile your idea of a "strict mode" with the existing standard. I
even started liking the idea, but you didn't even reply to that.

And I think you are somehow fixing on VLA, they are not the major
problem for your proposal. The thing is that the C comunity will not
swallow ABI changes easily. In C the responsibility for checking
function parameters is at the calling side. This is not likely to
change.

Introducing size information into some sort of "augmented pointers"
through the backdoor of references will be taken as what it is, ABI
change.

Jens

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

#1518

On 8/17/2012 12:00 PM, Jens Gustedt wrote:
> Hello,
> 
> Am 17.08.2012 18:40, schrieb John Nagle:
>> So, with C99 VLAs on the way out, it's appropriate to propose
>> alternatives.  Any alternative should potentially be portable
>> to C++.
> 
> I think you completely misunderstand the situation. That the C11
> standard makes VLA optional doesn't mean that they are phased
> out. They are optional like other parts of the language, e.g _Complex,
> _Atomic, thread support or the [u]intptr_t.
> 
> Many (most?) C compilers have VLA and will continue to have
> them. Making proposals than are not compatible with existing parts of
> the language, even if they are optional, will almost certainly be
> rejected very quickly. For the simple reason that the committee will
> not want to have contradicting parts inside the same standard, even if
> they are optional.
> 
>> My original proposal seems to fulfill that criterion.  It
>> starts with importing C++ references into C, and then
>> extends parameter syntax to support variable length
>> arrays in reference parameters.
>>
>> Take a look at this again on that basis, please.
> 
> Perhaps *you* should take a look again on what I developped at some
> point? I had the impression that there could be a path that could well
> reconcile your idea of a "strict mode" with the existing standard. I
> even started liking the idea, but you didn't even reply to that.

You wrote:
"There is certainly a potential for improvement in C where it allows to
assign pointers to differently sized VLA, considering them to be
compatible.

Here, at runtime, the information is available if the sizes fit, so it
should not be too difficult to implement a runtime check for this and
to throw some sort of runtime constraint violation. If you would
formalize that with a "strict" approach it could be a good start.

If in such a strict setting one still would do such an assignement,
one could easily cast this pointer through void* to rip off all type
(and size) information. So I don't think there would even be a need
for a new cast operator in C.

The runtime expenses for such a check would be moderate, since the
size information for the pointed-to-VLA is present at the place where
it is needed. In particular other pointers (not to VLA) would not be
affected."

That seemed a bit vague to work on.  Perhaps you could write up
your proposal in more detail.

The basic problem with VLAs is political.  Microsoft has explicitly
refused to implement them, so they're not used in anything that
has to be portable.  Microsoft's main objection is that they
don't fit into C++.  Microsoft may have a point.

> And I think you are somehow fixing on VLA, they are not the major
> problem for your proposal. The thing is that the C comunity (sic) will not
> swallow ABI changes easily. In C the responsibility for checking
> function parameters is at the calling side. This is not likely to
> change.

Nor does my proposal suggest that it should.  But I should be
more specific on what checks have to be made.  As an example,
if the function being called is

	void fn(size_t n, double (&mat)[n][n]);

and the call looks like

	const n
	double mat[10][10];
	...
	fn(10, mat);

on the call side, with checking enabled, we would want to
generate

	if (10 != lengthof(mat)) { runtime_constraint_violation(); }
	if (10 != lengthof(mat[0])) { runtime_constraint_violation(); }

which we would hope the compiler would reduce to
	
	if (10 != 10) ...

then optimize out.  That's how array sizes are passed reliably.

> Introducing size information into some sort of "augmented pointers"
> through the backdoor of references will be taken as what it is, ABI
> change.

No, no, I definitely am not proposing that.  Size information is
passed through some programmer-defined variable or variables, as
shown in the example above and in the paper.

				John Nagle

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

#1519

Le 17/08/12 22:30, John Nagle a écrit :

> The basic problem with VLAs is political.  Microsoft has explicitly
> refused to implement them, so they're not used in anything that
> has to be portable.

Portable to microsoft compilers that is. There are several C99
implementation under the windows systems.


> Microsoft's main objection is that they
> don't fit into C++.  Microsoft may have a point.
>

If you want C++.

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

#1522

Am 17.08.2012 22:30, schrieb John Nagle:
> That seemed a bit vague to work on.  Perhaps you could write up
> your proposal in more detail.

you write it up perfectly below

> The basic problem with VLAs is political.  Microsoft has explicitly
> refused to implement them, so they're not used in anything that
> has to be portable.  Microsoft's main objection is that they
> don't fit into C++.  Microsoft may have a point.

As somebody else already told you, Microsoft has refused a bunch of
other things from C99, and their compiler support for C on their own
platform lacks behind for years. They simply don't want people to
program in C.

But as I also already tried to explain, these politics are nothing you
can do much. If you want to make a proposal that will be accepted by
the C people, this proposal has to take care of VLA.

>> And I think you are somehow fixing on VLA, they are not the major
>> problem for your proposal. The thing is that the C comunity (sic) will not
>> swallow ABI changes easily. In C the responsibility for checking
>> function parameters is at the calling side. This is not likely to
>> change.

Now to your elaboration of what would happen in your "strict mode" if
I understand correctly:

> Nor does my proposal suggest that it should.  But I should be
> more specific on what checks have to be made.  As an example,
> if the function being called is
> 
> 	void fn(size_t n, double (&mat)[n][n]);
> 
> and the call looks like
> 
> 	const n
> 	double mat[10][10];
> 	...
> 	fn(10, mat);
> 
> on the call side, with checking enabled, we would want to
> generate
> 
> 	if (10 != lengthof(mat)) { runtime_constraint_violation(); }
> 	if (10 != lengthof(mat[0])) { runtime_constraint_violation(); }

I'd just suggest that this would better be formulated as

if ((10 != lengthof(mat)) || (10 != lengthof(mat[0]))) {
runtime_constraint_violation(); }

> which we would hope the compiler would reduce to
> 	
> 	if (10 != 10) ...
> 
> then optimize out.  That's how array sizes are passed reliably.

yes, this is exactly how I imagined, good.

With the subtle difference that I would just try to argue first for a
function that has no references in its parameter list. Just take

void fn(size_t n, double mat[n][n]);

as the prototype. All your arguments from above still work, you don't
need references for that.

(I also would add the same sort of test for the "double arr[static
100]" case.)

Now let us come to VLA. Already in what you define above, the function
fn has as second parameter a reference to VLA. In your thing with
references it would be a reference of a double[n][n] in my shorter
form it would be a pointer to double[n].

But what is essential, is that

 - the size expression is visible (and verifiable) for the caller.
 - the value that is effectively passed to the function is the start
   address of the array.

So basically to make your proposal work for parameters with sizes that
are not fixed at compile time, you simply need VLA (or something that
resembles much) for the description of the parameters.

Now, let us suppose that mat is also a VLA

double mat[argc][argc];

and the call is then

fn(argc, mat);

This would change the runtime verification that you are proposing to:

if ((argc != lengthof(mat)) || (argc != lengthof(mat[0]))) {
runtime_constraint_violation(); }

The only difference would be that it could not be optimized out
completely. (just perhaps one of them if the compiler is clever enough
to notice that lengthof(mat) == lengthof(mat[0]))

But optimizing this out completely is nothing you can expect if indeed
the size argc is dynamic. This is what runtime_constraint_violation is
made for.

To summarize:

 - you don't need the reference concept to make your proposal working
 - your proposal uses something very similar to VLA, anyhow
 - your proposal is easily able to cope with VLA (or pointer to VLA)
   that are passed in as parameters.

And your example also simply shows the force of the concept of VLA if
they are used to describe parameters of functions.

>> Introducing size information into some sort of "augmented pointers"
>> through the backdoor of references will be taken as what it is, ABI
>> change.
> 
> No, no, I definitely am not proposing that.  Size information is
> passed through some programmer-defined variable or variables, as
> shown in the example above and in the paper.

great

Jens

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

#1559

On 8/17/2012 4:07 PM, Jens Gustedt wrote:
> Am 17.08.2012 22:30, schrieb John Nagle:
>> That seemed a bit vague to work on.  Perhaps you could write up
>> your proposal in more detail.
> 
> you write it up perfectly below
> 
>> The basic problem with VLAs is political.  Microsoft has explicitly
>> refused to implement them, so they're not used in anything that
>> has to be portable.  Microsoft's main objection is that they
>> don't fit into C++.  Microsoft may have a point.
> 
> As somebody else already told you, Microsoft has refused a bunch of
> other things from C99, and their compiler support for C on their own
> platform lacks behind for years. They simply don't want people to
> program in C.
> 
> But as I also already tried to explain, these politics are nothing you
> can do much. If you want to make a proposal that will be accepted by
> the C people, this proposal has to take care of VLA.

What semantics could we give VLA parameters that would
keep all the size information around but not break anything
important?

Worse, how can fixed-length arrays be given similar semantics.
VLAs are rare, but fixed-length array parameters are not.

One option is to distinguish between fully-dimensioned arrays
and arrays where some dimension is unspecified.  That is,

	void fn1(size_t n, char s[]);

has an unspecified dimension, but

	void fn2(size_t n, int[n]);
	void fn3(int [100]);

are fully specified.

The unspecified case is a classic pointer.  The
fully specified case could potentially be handled
differently.

The way this ought to work is that, in this
example

	void fn4(int a1[100])
	{   int a2[100];
	}

a1 and a2 should have similar semantics. They
don't.

	a1++;	// error, not a lhs
	a2++;	// allowed
	sizeof(a1); // equals sizeof int
	sizeof(a2); // equals 100 * sizeof int

Changing that breaks too much involving fixed size
arrays.

How about this?

1.  Support the "pass by reference" described in the paper.
    Example:
	void fn5(int (&a1)[100]);
    Then
	sizeof(a1) // equals 100 * sizeof(int)

    Arrays passed by reference must be fully dimensioned.
	
2.  Permit, but deprecate, C99 style VLA parameters,
    if the implementation supports them at all.

			John Nagle

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

#1560

On 2012-08-20, John Nagle <nagle@animats.com> wrote:
> The way this ought to work is that, in this
> example
>
> 	void fn4(int a1[100])
> 	{   int a2[100];
> 	}
>
> a1 and a2 should have similar semantics. They
> don't.
>
> 	a1++;	// error, not a lhs
> 	a2++;	// allowed
> 	sizeof(a1); // equals sizeof int
> 	sizeof(a2); // equals 100 * sizeof int

One would expect that a1++ is allowed, a2++ is in error,
and that sizeof(a1) equals sizeof pointer-to-int.

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

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

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

csiph-web