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

#1453

Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
> On 14.08.2012 22:24, John Nagle wrote:
>> On 8/14/2012 12:09 PM, Hans-Bernhard Bröker wrote:
>>> On 14.08.2012 20:20, John Nagle wrote:
>>>> On 8/13/2012 10:23 PM, Keith Thompson wrote:
>>>
>>>>> C does not have parameters of array type.  "a" is not an array, it's a
>>>>> pointer.
>>
>>      It's a fully qualified array pointer,
>
> It is not, and it cannot be, because such a thing as an "array pointer" 
> does not exist in C.  There are pointers to arrays (the abovementioned 
> 'a' is one), and there arrays of pointers, but no "array pointers".

I'd say that "array pointer" is a reasonable informal way to refer to
a pointer to array type.  For example, the standard (N1370 K.3.7.3.1"
uses the phrase "char pointer" to refer to an object of type char*.

I agree that "pointer to array" is clearer.  (And I've seen
too many people use the phrase "double pointer" to refer to a
pointer-to-pointer rather than a pointer to type "double").

[...]

-- 
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]

#1484

On 15.08.2012 01:42, Keith Thompson wrote:
> Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
>> On 14.08.2012 22:24, John Nagle wrote:

>>>       It's a fully qualified array pointer,

>> It is not, and it cannot be, because such a thing as an "array pointer"
>> does not exist in C.  There are pointers to arrays (the abovementioned
>> 'a' is one), and there arrays of pointers, but no "array pointers".

> I'd say that "array pointer" is a reasonable informal way to refer to
> a pointer to array type.

Agreed.  But the way John Nagle is wielding the term, that doesn't seem 
to be what he meant by it.  So whatever that thing actually is supposed 
to be, at the very least it needs a different name.

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

#1491

Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
> On 15.08.2012 01:42, Keith Thompson wrote:
>> Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
>>> On 14.08.2012 22:24, John Nagle wrote:
>
>>>>       It's a fully qualified array pointer,
>
>>> It is not, and it cannot be, because such a thing as an "array pointer"
>>> does not exist in C.  There are pointers to arrays (the abovementioned
>>> 'a' is one), and there arrays of pointers, but no "array pointers".
>
>> I'd say that "array pointer" is a reasonable informal way to refer to
>> a pointer to array type.
>
> Agreed.  But the way John Nagle is wielding the term, that doesn't
> seem to be what he meant by it.  So whatever that thing actually is
> supposed to be, at the very least it needs a different name.

I agree that it wasn't entirely clear what he was referring to.  But the
full sentence was:

    It's a fully qualified array pointer, which has most of the
    behaviors of an array.

which implies an acknoledgement that it's *not* an array.  I think he
actually meant that it's a pointer to an array, which is correct, and he
used reasonable terminology to refer to it.

(What he then said about that pointer was incorrect; see my followup.)

-- 
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]

#1444

John Nagle <nagle@animats.com> writes:
> 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:
>> [...]
>
>>> void addscalar(int n, int m,
>>>     double a[n][n*m+300], double x)
>>> {
>>>     for (int i = 0; i < n; i++)
>>>         for (int j = 0, k = n*m+300; j < k; j++)
>>>         // a is a pointer to a VLA with n*m+300 elements
>>>             a[i][j] += x;
>>> }
> ...
>> 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.
>
>     Qualified pointers are mentioned in N1570 at
> "Simple Assignment" (6.5.16.1), and in "Array declarators",
> but they're never really discussed as a subject.  6.7.6.1 (Pointer
> declarators) says "For two pointer types to be compatible, both
> shall be identically qualified and both shall be pointers to
> compatible types." This would seem to imply that implementations
> should (or at least could) check VLA size match at function calls.

There are no qualifiers in this example.

>     It may thus be within the existing spec to take Annex K
> runtime-constraint action when sizes don't match.  That's
> a good first step to preventing buffer overflows.
>
>> So a is of type "pointer to array [n*m+300] of double".  sizeof a
>> is the size of that pointer. and sizeof a[0] is
>>     n*m*300 * sizeof (double).

Oops, I meant n*m + 300

>    GCC 4.5.3, at least, does not agree.  sizeof a[0] is the size
> of one row of the 2D array, not the whole array.  That's what
> I would have expected. sizeof(a) is the size of a pointer, here
> 4.  That's questionable.

Yes, it does.  Remember that the parameter is declared as:
    double a[n][n*m+300]
so sizeof a[0] is the size of a single row ((n*m+300) * sizeof (double).
The size of the entire array would be (n * (n*m+300) * sizeof (double).

And sizeof a is the size of a pointer; that's not questionable at all.
a is a pointer, *not* an array.  There is simply no such thing as an
array parameter in C.

>    It's questionable because sizeof results for a local VLA are
> different.  If I add
>
> 	double wrk[n][n];
>     	int siz1 = sizeof(wrk);
>     	printf("Size of wrk is %d\n", siz1);
>
> at the top of the function above (which is from N1570, Example 4,
> 6.7.6.3, which calls this with n=4), I get 128 from GCC.  That's
> 4*4*8, the full size of the array.  That's what should happen.

Yes, that's what should happen *in that case*, since wrk is an array
object.

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

Since there are no qualifiers in this example, the relevant portion is:

    A declaration of a parameter as "array of _type_ shall be
    adjusted to "pointer to _type_".

If you're thinking that the expression between the [ and ] is a
"qualifier", it isn't; the only type qualifiers are the keywords
const, restrict, volatile, and _Atomic.

>    Is this intentional, a GCC bug, or an ambiguity in the standard?

Yes, no, and no, respectively.

> It's certainly desirable to be able to obtain the size of an array
> when the language knows it.  "sizeof" shouldn't have different
> semantics depending upon whether an array is a a parameter or
> a local.  In practice, the use case for "sizeof" usually involves
> I/O, where getting the size wrong is a quick route to a buffer overflow.

The semantics of "sizeof" are entirely consistent.  The confusion in the
case of semothing that *looks like* an array parameter is the fact that
it *isn't* an array parameter; it's "adjusted" (at compile time) to a
pointer parameter.

This:

    void addscalar(int n, int m,
        double a[n][n*m+300], double x)

is by definition exactly equivalent to this:

    void addscalar(int n, int m,
        double (*a)[n*m+300], double x)

To take a simpler example, these are exactly equivalent:

    void func(double arr[100]);
    void func(double *arr);

And let me emphasize that this is not a "conversion" like the one
that occurs for most array expressions.  "double arr[100]", in that
context (and only in that context), is just another way of spelling
"double *arr".

(Personally, I really dislike the fact that the 100 is silently
ignored, but that's the way it is.)

If you propose changing the meaning of "double a[n][n*m+300]" when
it appears as a parameter declaration, you're going to break a lot
of existing code and implementations.

If you want C to have parameters of array type, you'll have to have
a new syntax for it.  C++ does have parameters of type "reference
to array", and you propose adding references to C; as long as you
stick to that and don't break the existing semantics, it's at least
conceivable your proposal could be accepted.  (I'm very skeptical
that it would be accepted, but you shouldn't necessarily let that
discourage you.)

-- 
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]

#1447

On 8/14/2012 2:59 PM, Keith Thompson wrote:
> John Nagle <nagle@animats.com> writes:
>> 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:

>> ...
>>>
>>> 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.
>>
>>     Qualified pointers are mentioned in N1570 at
>> "Simple Assignment" (6.5.16.1), and in "Array declarators",
>> but they're never really discussed as a subject.  6.7.6.1 (Pointer
>> declarators) says "For two pointer types to be compatible, both
>> shall be identically qualified and both shall be pointers to
>> compatible types." This would seem to imply that implementations
>> should (or at least could) check VLA size match at function calls.
> 
> 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?

				John Nagle

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

#1449

Am 15.08.2012 00:35, schrieb John Nagle:
> 
>     Oh, I see.  Qualifiers are allowed inside size declarations.
> This is valid:
> 
> 	double arr[const 100];
> 
> What's the use case for that, anyway?

this is only allowed for function parameters and there it is equivalent
to

double *const arr

that is a const-qualified pointer to non-qualified double

Jens

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

#1454

Le 15/08/12 00:51, Jens Gustedt a écrit :
> Am 15.08.2012 00:35, schrieb John Nagle:
>>
>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>> This is valid:
>>
>> 	double arr[const 100];
>>
>> What's the use case for that, anyway?
>
> this is only allowed for function parameters and there it is equivalent
> to
>
> double *const arr
>
> that is a const-qualified pointer to non-qualified double
>
> Jens
>

No, it says that the "arr" array is AT LEAST 100 elements wide!

"const" doesn't mean really "const" since it has been misused as a
marker to say that the array is AT LEAST that size.

These are C99 rules.

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

#1461

Am 15.08.2012 06:43, schrieb jacob navia:
> Le 15/08/12 00:51, Jens Gustedt a écrit :
>> Am 15.08.2012 00:35, schrieb John Nagle:
>>>
>>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>>> This is valid:
>>>
>>>     double arr[const 100];
>>>
>>> What's the use case for that, anyway?
>>
>> this is only allowed for function parameters and there it is equivalent
>> to
>>
>> double *const arr
>>
>> that is a const-qualified pointer to non-qualified double
>>
>> Jens
>>
> 
> No, it says that the "arr" array is AT LEAST 100 elements wide!
> 
> "const" doesn't mean really "const" since it has been misused as a
> marker to say that the array is AT LEAST that size.

No Jacob, I think you are mixing things up.

double arr[static 100]

would be what you suggest.

Jens

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

#1465

Le 15/08/12 08:31, Jens Gustedt a écrit :

>> No, it says that the "arr" array is AT LEAST 100 elements wide!
>>
>> "const" doesn't mean really "const" since it has been misused as a
>> marker to say that the array is AT LEAST that size.
>
> No Jacob, I think you are mixing things up.
>
> double arr[static 100]
>
> would be what you suggest.
>
> Jens
>

Yes, I was wrong

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

#1450

On 08/14/2012 06:35 PM, John Nagle wrote:
> On 8/14/2012 2:59 PM, Keith Thompson wrote:
>> John Nagle <nagle@animats.com> writes:
>>> 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:
> 
>>> ...
>>>>
>>>> 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.
...
>     Oh, I see.  Qualifiers are allowed inside size declarations.
> This is valid:
> 
> 	double arr[const 100];

This feature only applies in function parameter declarations. While
K&R-style function declarations are still supported, you should
definitely use function prototypes instead, in which case it would end
with a ',', not a ';'.

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

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

#1455

Le 15/08/12 00:58, James Kuyper a écrit :
> On 08/14/2012 06:35 PM, John Nagle wrote:
>> On 8/14/2012 2:59 PM, Keith Thompson wrote:
>>> John Nagle <nagle@animats.com> writes:
>>>> 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:
>>
>>>> ...
>>>>>
>>>>> 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.
> ...
>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>> This is valid:
>>
>> 	double arr[const 100];
>
> This feature only applies in function parameter declarations. While
> K&R-style function declarations are still supported, you should
> definitely use function prototypes instead, in which case it would end
> with a ',', not a ';'.
>
>> 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.

You are wrong.

That expression means that "aee" has AT LEAST 100 elements.

"const" in this context doesn't have anything to do with "const" in
other context. To avoid a new keyword the C standard (following the
bright examples of C++) has misused "const".


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

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

#1458

jacob navia wrote:
> 
> Le 15/08/12 00:58, James Kuyper a écrit :
> > On 08/14/2012 06:35 PM, John Nagle wrote:
> >> On 8/14/2012 2:59 PM, Keith Thompson wrote:
> >>> John Nagle <nagle@animats.com> writes:
> >>>> 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:
> >>
> >>>> ...
> >>>>>
> >>>>> 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.
> > ...
> >>      Oh, I see.  Qualifiers are allowed inside size declarations.
> >> This is valid:
> >>
> >> 	double arr[const 100];
> >
> >> 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.
> 
> You are wrong.
> 
> That expression means that "aee" has AT LEAST 100 elements.
> 
> "const" in this context doesn't have anything to do with "const" in
> other context. To avoid a new keyword the C standard (following the
> bright examples of C++) has misused "const".

No, it's the even more heavily overloaded "static" keyword which in that 
context means that "the value of the corresponding actual argument shall 
provide access to the first element of an array with at least as many 
elements as specified by the size expression."

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

#1467

On 08/15/2012 01:51 AM, Philip Lantz wrote:
> jacob navia wrote:
>>
>> Le 15/08/12 00:58, James Kuyper a �crit :
>>> On 08/14/2012 06:35 PM, John Nagle wrote:
>>>> On 8/14/2012 2:59 PM, Keith Thompson wrote:
>>>>> John Nagle <nagle@animats.com> writes:
>>>>>> On 8/13/2012 10:23 PM, Keith Thompson wrote:
...
>>>>>>> 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.
>>> ...
>>>>      Oh, I see.  Qualifiers are allowed inside size declarations.
>>>> This is valid:
>>>>
>>>> 	double arr[const 100];
>>>
>>>> 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.
>>
>> You are wrong.
>>
>> That expression means that "aee" has AT LEAST 100 elements.
>>
>> "const" in this context doesn't have anything to do with "const" in
>> other context. To avoid a new keyword the C standard (following the
>> bright examples of C++) has misused "const".

Does lcc-win32 implement this feature that way?

If that feature had, indeed, meant what jacob thought it meant, how
would it constitute "following the bright examples of C++"? The most
recent draft of the C+++ standard that I have is n3035.pdf, which is
fairly old (2010-02-16), but it's a full decade more current than the
C99 standard where this feature was introduced, and this feature was NOT
present in that version of the C++ standard. Is jacob referring to some
other "misuse" of 'const'? I suppose he could be referring to the way
C++2003 changed the meaning of 'auto', but that didn't occur until long
after this feature was added to C99, so "following the example" could
apply only if a time machine were involved.

Personally, I approve of the new meaning for auto - I haven't had a good
reason to use it yet, but it seems like it could be useful, especially
in C++ templates. What little value the old meaning of 'auto' had
disappeared with the removal of implicit int.
-- 
James Kuyper

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

#1468

Am 15.08.2012 13:18, schrieb James Kuyper:
> On 08/15/2012 01:51 AM, Philip Lantz wrote:
>> jacob navia wrote:
>>> "const" in this context doesn't have anything to do with "const" in
>>> other context. To avoid a new keyword the C standard (following the
>>> bright examples of C++) has misused "const".
> 
> Does lcc-win32 implement this feature that way?

Could you please stop picking at each other, at the committe or who
ever? Or at least transfer that to comp.lang.c? So far comp.std.c has
mostly been a place that had rational posts, it would be a pity if
you'd manage to pollute this ng here also with your pointless wars.

I know it was Jacob who started insulting people (including myself) on
that same issue and that he only was able to produce a pointless
excuse afterward, instead of a full grown apology. But so what?

May I remind you that your first encounter with [const] upthread was
not the most competent contributions that we have seen from you in
this ng, either?

This is a thread on bound checking in C. C has an interface for that
in functions, namely [static]. We discussed bound checking here (for
how many hours?) and nobody even came up with discussion this existing
interface, me including.

An interesting question would be if anybody knows a compiler that
actually uses the [static] interface for a real size check. This could
be done e.g in the following situation:

void f(double a[static 100]);

double b[99];
double *c = malloc(sizeof(double[n]));
double *d = 0;
f(b);           // <- issue a diagnostic here
f(c);           // <- can't expect a diagnostic
f(d);           // <- a good compiler could issue a diagnostic here

I only vaguely remember that some compilers use this to enforce that a
pointer argument that is passed to the function must not be 0 as for
"d". (was that gcc or clang?). But I didn't hear of anybody using the
full information.

Jens

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

#1469

Le 15/08/12 14:15, Jens Gustedt a écrit :
> I know it was Jacob who started insulting people (including myself) on
> that same issue and that he only was able to produce a pointless
> excuse afterward, instead of a full grown apology. But so what?

Well, an excuse is not pointless.

I apologize again, if you deem this necessary. I confused this const 
with static in the context of an argument declaration, and I was unduly 
polemic, convinced that I was right (maybe as James is :-) )

I agree that we should stop this, and will try to be less polemic in the 
future (including to James)

jacob

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

#1470

Am 15.08.2012 14:28, schrieb jacob navia:
> Le 15/08/12 14:15, Jens Gustedt a écrit :
>> I know it was Jacob who started insulting people (including myself) on
>> that same issue and that he only was able to produce a pointless
>> excuse afterward, instead of a full grown apology. But so what?
> 
> Well, an excuse is not pointless.
> 
> I apologize again, if you deem this necessary. I confused this const
> with static in the context of an argument declaration, and I was unduly
> polemic, convinced that I was right (maybe as James is :-) )
> 
> I agree that we should stop this, and will try to be less polemic in the
> future (including to James)
> 
> jacob

Thanks, Jacob.

I take the advantage of asking your opinion directly as one of the
compiler implementors that we have at hand here.

Do you think that implementing a bound check with the [static]
interface for function parameters would be easy to do? Does your
compiler provide this?

I know from other compilers (the gcc family has "attributes") that can
glue additional properties to individual function parameters. So for
them implementing at least the compile time check if an array is
passed to the function should be not too difficult, I guess.

Jens

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

#1471

Le 15/08/12 14:36, Jens Gustedt a écrit :
> Am 15.08.2012 14:28, schrieb jacob navia:
>> Le 15/08/12 14:15, Jens Gustedt a écrit :
>>> I know it was Jacob who started insulting people (including myself) on
>>> that same issue and that he only was able to produce a pointless
>>> excuse afterward, instead of a full grown apology. But so what?
>>
>> Well, an excuse is not pointless.
>>
>> I apologize again, if you deem this necessary. I confused this const
>> with static in the context of an argument declaration, and I was unduly
>> polemic, convinced that I was right (maybe as James is :-) )
>>
>> I agree that we should stop this, and will try to be less polemic in the
>> future (including to James)
>>
>> jacob
>
> Thanks, Jacob.
>
> I take the advantage of asking your opinion directly as one of the
> compiler implementors that we have at hand here.
>
> Do you think that implementing a bound check with the [static]
> interface for function parameters would be easy to do?

Yes, that doesn't look difficult. It means just not destroying the
size information in the parameters and treat them like a local variable.
Actually it means that all the code in the compiler that does
the necessary adjustments is moot and can be discarded!

Since there are NO adjustments to do, an array is just as any other
parameter.

I have implemented references in my compiler as Mr Nagle proposes.
If we would agree in the semantics for references to arrays that
would be quite easy to do...

> Does your
> compiler provide this?
>

No, since I went the operator overloading solution. That solution is 
much more general and provides a lot MORE solutions to many overflow
problems without affecting old code.

1) Allows for seamless implementation of a bounds checked string library
with exactly the same syntax as strcpy strchr, etc. You get bounds 
checked strings also, not only arrays.

2) You get a solution for the proliferation of numeric types. We have
   several technical reports proposing decimal numbers, fixed point
   numbers, we had complex numbers (that now are optional) etc. Operator
   overloading would allow us to accept all those proposals without
   making the whole language unduly complex. The problem is that now
   if you accept those proposals you would prescribe them for ALL users,
   even for the ones that do NOT need them! Operator overloading allows
   users to define their own types (the standard could standardize
   some solutions using operator overloading) but they wouldn't be
   a *mandatory* part of the language.

jacob
> I know from other compilers (the gcc family has "attributes") that can
> glue additional properties to individual function parameters. So for
> them implementing at least the compile time check if an array is
> passed to the function should be not too difficult, I guess.

No, but that is a partial solution. A full solution would be to NOT
rely on just the compile time checks and have a bounds checked
solution at run time. This is slower than no checking of course
but it would slow down programs by a very small amount. It means each
array access has an integer comparison and a conditional jump 
instructions more. This doesn't mean anything if the compiler arranges 
for a forward branch since it will be correctly predicted and
the pipeline will not stall.

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

#1472

Am 15.08.2012 14:54, schrieb jacob navia:
> Le 15/08/12 14:36, Jens Gustedt a écrit :
>> Am 15.08.2012 14:28, schrieb jacob navia:
>> I know from other compilers (the gcc family has "attributes") that can
>> glue additional properties to individual function parameters. So for
>> them implementing at least the compile time check if an array is
>> passed to the function should be not too difficult, I guess.
> 
> No, but that is a partial solution. A full solution would be to NOT
> rely on just the compile time checks and have a bounds checked
> solution at run time. This is slower than no checking of course
> but it would slow down programs by a very small amount. It means each
> array access has an integer comparison and a conditional jump
> instructions more. This doesn't mean anything if the compiler arranges
> for a forward branch since it will be correctly predicted and
> the pipeline will not stall.

I didn't wanted to imply that the dynamic check shouldn't be done. My
idea was just that the compile time check would be easier to do and
incur no runtime penalty at all (almost by definition of a compile
time check :)

For the penalty of the dynamic check there are two things to
consider. The first is the additional branch instruction, I agree that
this should be minimal as you say because the correct branch could
easily predicted. (But a lot of people would insist that they don't
want this, I guess, by fear of having a penalty.)

What is perhaps more important, is that such a feature might hinder
certain optimizations. If you have a VLA for which sizeof is never
used the implicit size "variable" that is hidden somewhere could be
optimized out.

Jens

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

#1480

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?
[...]

For example:

    void func(double arr[static 100]);

This requires a double* pointer that can be used to access an array of
at least 100 elements.  Passing a double* that points to (the first
element of) a shorter array causes undefined behavior, which in
principle opens up the possibility of doing bounds checking.

But where does the bounds information come from?  Would the compiler
pass extra implicit parameters specifying the bounds of the array that
the argument points into?  Or would you use "fat pointers", so that a
double* contains both an address and bounds information?

Unless *every* pointer carries extra information, there are going to be
cases where the bounds information isn't available.  For example,
suppose you call func() with an argument whose value comes from a
separately compiled function that the compiler knows nothing about
except that it returns a double*.

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.

-- 
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]

#1486

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

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

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

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

csiph-web