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

#1504

On 08/16/2012 02:04 PM, Keith Thompson wrote:
...
> Were there any compilers that didn't support VLAs whose authors
> expressed any interest in supporting C99?  Microsoft's C compiler
> doesn't support VLAs, but it neither does it support mixing declarations
> and statements within a block (as of Microsft Visual C++ 2010 Express).
> Presumably making VLAs optional won't make any difference in what
> Microsoft decides to do.

I know that for gcc, up to and including version 4.3, "Some details of
variable length arrays (VLAs) relating to when size expressions are
evaluated and when the memory for VLAs is freed are not implemented, and
other details are not checked against the requirements of the C99
standard." However, that issue was apparently resolved in version 4.4.
See  <http://gcc.gnu.org/c99status.html> for the current status, and
links to status for earlier versions.

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

#1505

James Kuyper <jameskuyper@verizon.net> writes:
> On 08/16/2012 02:04 PM, Keith Thompson wrote:
> ...
>> Were there any compilers that didn't support VLAs whose authors
>> expressed any interest in supporting C99?  Microsoft's C compiler
>> doesn't support VLAs, but it neither does it support mixing declarations
>> and statements within a block (as of Microsft Visual C++ 2010 Express).
>> Presumably making VLAs optional won't make any difference in what
>> Microsoft decides to do.
>
> I know that for gcc, up to and including version 4.3, "Some details of
> variable length arrays (VLAs) relating to when size expressions are
> evaluated and when the memory for VLAs is freed are not implemented, and
> other details are not checked against the requirements of the C99
> standard." However, that issue was apparently resolved in version 4.4.
> See  <http://gcc.gnu.org/c99status.html> for the current status, and
> links to status for earlier versions.

Right, so making VLAs optional in C11 doesn't help gcc, since it
implements them anyway.

Perhaps some implementers just decided C99 as a whole was too big to
implement, and would have been substantially easier without VLAs?

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

#1506

On 08/16/2012 02:47 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 08/16/2012 02:04 PM, Keith Thompson wrote:
>> ...
>>> Were there any compilers that didn't support VLAs whose authors
>>> expressed any interest in supporting C99?  Microsoft's C compiler
>>> doesn't support VLAs, but it neither does it support mixing declarations
>>> and statements within a block (as of Microsft Visual C++ 2010 Express).
>>> Presumably making VLAs optional won't make any difference in what
>>> Microsoft decides to do.
>>
>> I know that for gcc, up to and including version 4.3, "Some details of
>> variable length arrays (VLAs) relating to when size expressions are
>> evaluated and when the memory for VLAs is freed are not implemented, and
>> other details are not checked against the requirements of the C99
>> standard." However, that issue was apparently resolved in version 4.4.
>> See  <http://gcc.gnu.org/c99status.html> for the current status, and
>> links to status for earlier versions.
> 
> Right, so making VLAs optional in C11 doesn't help gcc, since it
> implements them anyway.

I meant that as an example of how VLAs delayed full implementation of
C99, not as an example of how making them optional could speed up full
implementation of C2011.

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

#1488

Hans-Bernhard Bröker <HBBroeker@t-online.de> writes:
> On 15.08.2012 22:00, John Nagle wrote:
>>     Occurrences of "sizeof" on fixed length arrays also appear to be
>> rare to nonexistent in the corpus of C code known to Google Code Search.
>
> If so, then that either appearance is grievously misleading, or Google 
> doesn't really have a representative sample of real-world C code.

I'd expect "sizeof arr / sizeof arr[0]" to be fairly common.  If it's
wrapped in a macro, you wouldn't see many occurrences of it.

Then again, perhaps fixed length arrays aren't all that common;
dynamically allocated arrays are awkward but *much* more flexible.

>> VLAs are already an optional feature in the current C standard draft.
>
> Given they were a _non_-optional feature of the previous actual standard 
> of 1999, I'd like a draft number, chapter and verse before I believe that.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

6.7.6.2p4, "Array declarators":
    Variable length arrays are a conditional feature that
    implementations need not support; see 6.10.8.3

6.10.8.3, "Conditional feature macros":

    __STDC_NO_VLA__ The integer constant 1, intended to indicate that
        the implementation does not support variable length arrays or
        variably modified types.

Other optional features are analyzability (annex L), IEC 559
floating-point, bounds-checking interfaces (annex K), atomics, complex
numbers, and threads.

>> The existing approach, after 13 years, has been rejected by the
>> market.
[...]

It's been rejected by Microsoft, but Microsoft has effectively rejected
almost everything newer than C90 (except for *some* features that are
also in C++).  I'm not convinced that it's been rejected by providers
other than Microsoft, or by programmers who don't depend on Microsoft's
implementation.

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

#1496

All,

On 15/08/2012 21:00, John Nagle wrote:
...
>     Occurrences of "sizeof" on fixed length arrays also appear to be
> rare to nonexistent in the corpus of C code known to Google Code Search.

According to my measurements 12% of sizeof operands have an
array type.

See table 1118.1 in www.knosof.co.uk/cbook/cbook1_2.pdf

If I were to redo the measurements today I would use Coccinelle:
http://shape-of-code.coding-guidelines.com/2009/01/08/semantic-pattern-matching-coccinelle/

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

#1497

On 8/16/2012 4:39 AM, Derek M. Jones wrote:
> All,
> 
> On 15/08/2012 21:00, John Nagle wrote:
> ...
>>     Occurrences of "sizeof" on fixed length arrays also appear to be
>> rare to nonexistent in the corpus of C code known to Google Code Search.
> 
> According to my measurements 12% of sizeof operands have an
> array type.

   How many of those are VLAs, and how many are VLA array parameters?

   That's the big question here.  VLA array parameters seem to be quite
rare, even in code where they would be useful, such as math libraries.
I'm still trying to find even one example of a VLA array parameter
in open source code.  There are none in the corpus that Google Code
Search covers.

					John Nagle

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

#1500

On 08/16/2012 12:57 PM, John Nagle wrote:
> On 8/16/2012 4:39 AM, Derek M. Jones wrote:
>> All,
>>
>> On 15/08/2012 21:00, John Nagle wrote:
>> ...
>>>     Occurrences of "sizeof" on fixed length arrays also appear to be
>>> rare to nonexistent in the corpus of C code known to Google Code Search.
>>
>> According to my measurements 12% of sizeof operands have an
>> array type.
> 
>    How many of those are VLAs, and how many are VLA array parameters?
> 
>    That's the big question here.

This sub-thread traces back to my non-serious proposal that the standard
be modified to explicitly specify that the value of sizeof be determined
prior the adjustment that converts a parameter declared as an array into
a parameter that's actually a pointer. The associated quantitative issue
is how much code would be broken by such a change. Given a function
defined as follows:

	int func(
	    size_t n,
	    double left[n],
	    double (*middle)[n],
	    double right[4])
	{

With the standard as currently written, sizeof(left)==sizeof(double*),
and sizeof(right)==sizeof(double*). With my non-serious proposal,
sizeof(left)==n*sizeof(double), sizeof(right)==4*sizeof(double). Any
such code which uses sizeof(left), or sizeof(right), expecting it to
give the currently correct value, would break if that proposal were adopted.

Note that "middle" is the only argument with a variably-modified type
("left" and right are both ordinary pointers), yet it's unaffected by
this proposal. sizeof(middle)==sizeof(double(*)[n]), whether or not that
proposal were approved.

Therefore, VLAs are NOT the big question, at least not in this sub-thread.

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

#1511

On 16/08/2012 17:57, John Nagle wrote:
>> According to my measurements 12% of sizeof operands have an
>> array type.
>
>     How many of those are VLAs, and how many are VLA array parameters?

I suspect none because I picked the source just after C99 was published
to be representable of the day.

>     That's the big question here.  VLA array parameters seem to be quite
> rare, even in code where they would be useful, such as math libraries.
> I'm still trying to find even one example of a VLA array parameter
> in open source code.  There are none in the corpus that Google Code
> Search covers.

Google code does not contain a particularly wide selection and there
are lots of duplicates.

You could use the techniques I used for many of the measurements in
my C book (source of tool available via www.knosof.co.uk/cbook)
to search a recent Linux distribution source collection.

If you use the search technique from the numbers tool you
won't even have to extract the files from their compressed form:
http://www.coding-guidelines.com/numbers/

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

#1474

On 15.08.2012 08:05, Philip Lantz wrote:

> It has the potential to break existing code, but I would bet that most
> code that applies sizeof to a parameter declared as an array is already
> broken.

"Most" is pretty much irrelevant.  Either there's a way to prove that 
_all_ such code must be broken already, or there isn't.  If there isn't, 
that generally warrants a judgment, which indeed is:

> Still unacceptable, though.

> However, introducing a new operator to get the size information for a
> parameter that was declared as an array (before it was adjusted to a
> pointer) seems doable.

Not without introducing and using some new syntax to indicate the 
programm author's intent to use this new feature.  Passing more 
information for _all_ functions with array arguments breaks the 
application binary interface (ABI), and thus essentially all existing 
interfaces to binary code (think: kernel interfaces, shared libcs...). 
I.e. the compiler _has_ to still be able to not pass that secret new 
data, and that _has_ to be the default behaviour for all existing code. 
  So new code has to bear some mark that it wants/needs this extra 
information passed.

> The compiler would just have to remember that it was
> originally written the other way,

Given the fact you're talking about trashing every single ABI in 
existence, that's a pretty big "just".

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

#1476

Le 15/08/12 18:56, Hans-Bernhard Bröker a écrit :
> Not without introducing and using some new syntax to indicate the
> programm author's intent to use this new feature.

Can you explain why the operator overloading solution is not a better
solution that trying to "fix" this?

It is impossible without destroying backwards compatibility as everyone
agrees.

Why then, can't we propose the operator overloading solution that
would fix this and several OTHER problems ?

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

#1494

Hans-Bernhard Bröker wrote:
> On 15.08.2012 08:05, Philip Lantz wrote:
> > However, introducing a new operator to get the size information for
> > a parameter that was declared as an array (before it was adjusted to
> > a pointer) seems doable.
> 
> Not without introducing and using some new syntax to indicate the 
> programm author's intent to use this new feature.  Passing more 
> information for _all_ functions with array arguments breaks the 
> application binary interface (ABI), and thus essentially all existing 
> interfaces to binary code (think: kernel interfaces, shared libcs...). 
> I.e. the compiler _has_ to still be able to not pass that secret new 
> data, and that _has_ to be the default behaviour for all existing code. 
>   So new code has to bear some mark that it wants/needs this extra 
> information passed.
> 
> > The compiler would just have to remember that it was
> > originally written the other way,
> 
> Given the fact you're talking about trashing every single ABI in 
> existence, that's a pretty big "just".

That's not what I'm talking about.

I'm talking about an operator that will give the array size of a 
parameter where the size is known, such as:

void f1(int a[5])
void f2(int n, char b[n])

I think that this was the goal of the OP.

If the programmer tried to apply this new proposed operator to a 
parameter where the array size is not known, that would be a constraint 
violation.

There's no need for the programmer to indicate an intent to use the 
operator, other than to use it. (Yes, the compiler would have to keep 
some additional information around in case it's needed. I think the cost 
of that is minimal.)

Now, you may think that I'm setting my sights too low, and that what we 
really need is for something like this to work:

size_t f(int a[]) { return lengthof a; }
size_t g() { int b[5]; return f(b); } // returns 5

You're right, that would require significantly more changes; that's why 
I'm *not* suggesting it.

Philip

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

#1498

On 16.08.2012 06:47, Philip Lantz wrote:
> Hans-Bernhard Bröker wrote:

>> Given the fact you're talking about trashing every single ABI in
>> existence, that's a pretty big "just".

> That's not what I'm talking about.

> I'm talking about an operator that will give the array size of a
> parameter where the size is known, such as:
>
> void f1(int a[5])
> void f2(int n, char b[n])

The implementor of f1 and f2 doesn't need any new operator to get at at 
_that_ information.  He can just write `5' or `n', respectively.

But that's OK, actually, because that is not the information needed to 
avoid buffer overflows, in the first place.  What you need is the size 
of the _actual_ argument, and that cannot possibly be known to any other 
party but the calling function.  Not in the general case, anyway.

So for that information to be available in the called function, it has 
to be passed to it some way.  This means the size of the actual array 
has to become a hidden argument to be passed to the function (a bit like 
the `this' pointer in C++ methods), and that's the change of ABI that 
you believe you're not talking about.

Another problem with that idea is that for 20+ years now the expressions 
inside those [] have been totally meaningless, and are therefore hardly 
ever actually spelled out except by newbies who haven't learned that 
yet.  And since nothing changes if you get those numbers horribly wrong, 
any such numbers that are present in existing code will most likely be 
random garbage anyway.

Suddenly ascribing a meaning to an existing syntactical element that has 
been, for all intents and purposes, nothing more than an unusual type of 
comment, can only lead to mayhem with existing code.

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

#1503

Am 16.08.2012 19:14, schrieb Hans-Bernhard Bröker:
> On 16.08.2012 06:47, Philip Lantz wrote:
>> Hans-Bernhard Bröker wrote:
> 
>>> Given the fact you're talking about trashing every single ABI in
>>> existence, that's a pretty big "just".
> 
>> That's not what I'm talking about.
> 
>> I'm talking about an operator that will give the array size of a
>> parameter where the size is known, such as:
>>
>> void f1(int a[5])
>> void f2(int n, char b[n])
> 
> The implementor of f1 and f2 doesn't need any new operator to get at at
> _that_ information.  He can just write `5' or `n', respectively.
> 
> But that's OK, actually, because that is not the information needed to
> avoid buffer overflows, in the first place.  What you need is the size
> of the _actual_ argument, and that cannot possibly be known to any other
> party but the calling function.  Not in the general case, anyway.
> 
> So for that information to be available in the called function, it has
> to be passed to it some way.  This means the size of the actual array
> has to become a hidden argument to be passed to the function (a bit like
> the `this' pointer in C++ methods), and that's the change of ABI that
> you believe you're not talking about.

But there is just no need this information in the called function. As
far as I see, nowhere in C there is an obligation of the called
function to check for the validity of a parameter. It is always the
obligation for the calling side to provide the correct
arguments. (Think of printf, e.g)

And C has a construct for the first case (f1 above) that lets us name
an expectation about the size of the array that is to be passed to the
function, at least for the first case.

void f1(int a[static 5])

*makes* a difference to

void f1(int *a)

it tells the caller that at least 5 elements are expected. The ABI is
the same, but the semantic for the calling side has changed.

If the argument is indeed an array this is trivial to check:

int B[4] = { 0 };
f1(B);

This is UB. But it is easy to check even at compile time, so one could
constrain this without difficulties.

Nobody seems to have implemented this (at least I didn't receive an
answer for my question upthread.)

For

int C[n];  // n a variable
f1(C);

this can easily be checked at runtime and the bounds checking
interface of C11 could give a tool to handle this.

For

void f2(int n, char b[n])

the situation is a bit more complicated since, as you say, a
previously "meaningless" syntactic sugar all of a sudden receives a
meaning. (well only for the innermost dimenson, it well has one for
other dimensions.)

Here comes John's "strict mode". Don't change the meaning of the above
in normal compilation, but when in "strict mode" require that all
declarations and definitions agree on the expressions inside []. Then,
take these expressions for the check at the calling side. No need at
all to change the ABI, to transfer information to the called side or
anything like that.

Jens

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

#1432

On 08/14/2012 02:20 PM, John Nagle wrote:
...
> ... This would seem to imply that implementations
> should (or at least could) check VLA size match at function calls.

See 6.7.6.2p9 for examples of how compatibility rules apply to arrays
with variably-modified types.

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

#1433

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.

> compatible types." This would seem to imply that implementations
> should (or at least could) check VLA size match at function calls.

No, they shouldn't, because, as Keith just told you above, there is no 
such thing as "a VLA ... at function calls".  No other non-VL array, 
either, for that matter.  A function argument simply is _never_ an array.

>   sizeof(a) is the size of a pointer, here 4.  That's questionable.

No, it's not.  That's what C has been doing since the dawn of time. 
sizeof(a) yields the size of a pointer for the least questionable reason 
there could be: because 'a' _is_ a pointer.

>     It's questionable because sizeof results for a local VLA are
> different.

No it's not, because that 'a' is not a VLA at all, so the argument 
doesn't apply to it.

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

The former.

> It's certainly desirable to be able to obtain the size of an array
> when the language knows it.

But in the case at hand the language _doesn't_ know it.

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

#1438

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, which has most of the
behaviors of an array.  The actual parameter (at the call) can
be an array, and the type will match.  The corresponding formal
parameter can be written as an array, with dimensions.
Within the function, the parameter is subscripted as if an array,
including multidimensional array subscripting that requires size
information.  Most of the operations that work on arrays thus work on
fully qualified array pointers as if they were arrays.

    The main exceptions are type matching (in the form of
array size checking) and "sizeof".  Size mismatches are undefined
behavior, so an implementation could, if so desired, check.
"sizeof" remains a problem.

>>   sizeof(a) is the size of a pointer, here 4.  That's questionable.
> 
> No, it's not.  That's what C has been doing since the dawn of time.

    True.  And here's the mess it creates, even for a fixed size array:

typedef double mat4[4][4];
void fn1(mat4 m0)
{   mat4 m1;
    size_t s0 = sizeof(m0);
    size_t s1 = sizeof(m1);
    printf("Size of m0 is %d.\nSize of m1 is %d", s0, s1);
}

Size of m0 is 4.
Size of m1 is 128

This is not good.

Until VLAs came in, it didn't matter much. But once VLAs were
provided, and "sizeof" extended to retrieve their size information,
these semantics became troublesome.  Especially since "sizeof" is
the only means provided to access VLA size information.
> 
>>     Is this intentional, a GCC bug, or an ambiguity in the standard?
> The former.

   A way out of this may be to define "lengthof" or some other
suitable name.  "lengthof" would return the number of elements of an
array or a fully qualified array pointer.   This would encourage
programmers to write

	for (int i=0; i<lengthof(arr); i++)
	{  fn(arr[i]); } // do something with each element

which is clean code and a good way to eliminate buffer overruns in
for loops.

(There still should be some way to get the size of the array
pointed to by a fully qualified array pointer.  Something
that would work consistently for anything subscriptable, or
be rejected at compile time as ambiguous. Suggestions?)

>> It's certainly desirable to be able to obtain the size of an array
>> when the language knows it.
> 
> But in the case at hand the language _doesn't_ know it.

   Array size information is used for subscript calculations for
multidimensional array parameters.  That was the main point of
introducing variable length array parameters.  The language
does know about sizes.  It just won't tell the programmer.

   Going back to my original "strict mode" proposal, I'm
starting to see how to do this.  The general idea would be
to require the newer syntax in strict code, always passing
arrays as fully qualified array pointers, rather than the
various old ways of passing arrays with unspecified length.
Non-strict modules could still call strict modules and vice
versa, provided that the function declarations include the
necessary size information.

				John Nagle

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

#1439

On 08/14/2012 04:24 PM, 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, which has most of the
> behaviors of an array.

For all purposes, it behaves exactly as if 'a' had been declared as
double (*a)[n*m+300]. Would you still call it an array if it had been
declared that way?

>>> It's certainly desirable to be able to obtain the size of an array
>>> when the language knows it.
>>
>> But in the case at hand the language _doesn't_ know it.
> 
>    Array size information is used for subscript calculations for
> multidimensional array parameters.  That was the main point of
> introducing variable length array parameters.  The language
> does know about sizes.  It just won't tell the programmer.

In the declaration of a function parameter as double a[n][n*m+300], the
language as it's currently defined gives the implementation no reason to
keep track of the first 'n'. It is not used in any subscript
calculations. It can be discarded shortly after entering phase 8, just
the same as if 'n' had been a '3'.

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

#1446

John Nagle <nagle@animats.com> writes:
> 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,

Yes.

>                                           which has most of the
> behaviors of an array.

No, it really doesn't.  If you find yourself thinking that arrays and
pointers are in any sense the same thing, or even that they have common
characteristics that they don't share with other types, you need to step
back for a moment and re-think your position.

>                         The actual parameter (at the call) can
> be an array, and the type will match.

The actual parameter can be an expression of array type, but that
expression will be converted to a pointer, and it's that pointer value
that's passed to the function.  Any bounds information associated with
the array is lost by the conversion.

Given:

    void func(double arr[10]);

    double obj[10];

these calls:

    func(obj);
    func(&obj[0]);

are exactly equivalent.  They both pass an argument of type double* to
func(), where the pointer parameter "arr" takes on the value of that
argument.  C's array-to-pointer conversion rule, and it's separate
array-to-pointer adjustment rule, seem to conspire to hide that fact,
something that I personally consider unfortunate.

Hmm.  Have you read section 6 of the comp.lang.c FAQ,
<http://www.c-faq.com/>?

>                                        The corresponding formal
> parameter can be written as an array, with dimensions.

Yes, it can be written that way, but it's nothing more than an alternate
spelling of a formal parameter of pointer type.  It's not pretty, but
it's true, and it can't change without breaking existing code.

> Within the function, the parameter is subscripted as if an array,
> including multidimensional array subscripting that requires size
> information.  Most of the operations that work on arrays thus work on
> fully qualified array pointers as if they were arrays.

The indexing operation [] is defined to work on *pointers*, not arrays.
It requires two operands, one of pointer type and one of integer type
(in either order, but it's moderately insane to give the integer operand
first).

N1570 6.5.2.1p2:

    The definition of the subscript operator [] is that E1[E2] is
    identical to (*((E1)+(E2))).

It's very common for E1 to be an expression of array type, but that
expression must be converted to pointer type before the [] operator can
be applied.

>     The main exceptions are type matching (in the form of
> array size checking) and "sizeof".  Size mismatches are undefined
> behavior, so an implementation could, if so desired, check.
> "sizeof" remains a problem.

The current rules are admittedly confusing but entirely consistent.  Oh,
and size mismatches in the sense you seem to mean are not undefined
behavior.  This:

    void func(int arr[10]);

    int obj[100];

    func(obj);

is perfectly legal and has well-defined behavior, as long as the body of
func() doesn't access any elements past arr[9].

>>>   sizeof(a) is the size of a pointer, here 4.  That's questionable.
>> 
>> No, it's not.  That's what C has been doing since the dawn of time.
>
>     True.  And here's the mess it creates, even for a fixed size array:
>
> typedef double mat4[4][4];
> void fn1(mat4 m0)
> {   mat4 m1;
>     size_t s0 = sizeof(m0);
>     size_t s1 = sizeof(m1);
>     printf("Size of m0 is %d.\nSize of m1 is %d", s0, s1);
> }
>
> Size of m0 is 4.
> Size of m1 is 128
>
> This is not good.

(Since s0 and s1 are of type size_t, you should cast them to int to
match the "%d" conversion specification.)

m1 is a pointer. m1 is an array.  Of course they have different sizes.

> Until VLAs came in, it didn't matter much. But once VLAs were
> provided, and "sizeof" extended to retrieve their size information,
> these semantics became troublesome.  Especially since "sizeof" is
> the only means provided to access VLA size information.
>> 
>>>     Is this intentional, a GCC bug, or an ambiguity in the standard?
>> The former.
>
>    A way out of this may be to define "lengthof" or some other
> suitable name.  "lengthof" would return the number of elements of an
> array or a fully qualified array pointer.   This would encourage
> programmers to write
>
> 	for (int i=0; i<lengthof(arr); i++)
> 	{  fn(arr[i]); } // do something with each element
>
> which is clean code and a good way to eliminate buffer overruns in
> for loops.
>
> (There still should be some way to get the size of the array
> pointed to by a fully qualified array pointer.  Something
> that would work consistently for anything subscriptable, or
> be rejected at compile time as ambiguous. Suggestions?)

I'm not sure what you mean by "fully qualified".  The only type
qualifiers are the keywords const, restrict, volatile, and _Atomic.
Can you think of a different phrase for what you're trying to
refer to?

Again, if arr is defined as a parameter like "double arr[some_size]",
then there is no way lengthof(arr) can work; the array size information
has already been discarded.

>>> It's certainly desirable to be able to obtain the size of an array
>>> when the language knows it.
>> 
>> But in the case at hand the language _doesn't_ know it.
>
>    Array size information is used for subscript calculations for
> multidimensional array parameters.  That was the main point of
> introducing variable length array parameters.  The language
> does know about sizes.  It just won't tell the programmer.

A parameter cannot be of array type, so you can't ask about the length
of a parameter.  A parameter *can* be of pointer-to-array type, so you
can ask about the length of what a parameter points to.

The language *doesn't know* about the size of the array object
corresponding to something that looks like an array parameter.  The
length can vary from one call to another, and the length information is
quietly discarded (unless you pass it explicitly as another argument).

>    Going back to my original "strict mode" proposal, I'm
> starting to see how to do this.  The general idea would be
> to require the newer syntax in strict code, always passing
> arrays as fully qualified array pointers, rather than the
> various old ways of passing arrays with unspecified length.
> Non-strict modules could still call strict modules and vice
> versa, provided that the function declarations include the
> necessary size information.

You really need to thoroughly understand how pointers and arrays work
in C as it's defined now before you can reasonably propose changes.
If there's anything in section 6 of the comp.lang.c FAQ that you
don't already understand, or that you think is wrong, then I submit
that you're not ready.

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

#1459

Keith Thompson wrote:

> Again, if arr is defined as a parameter like "double arr[some_size]",
> then there is no way lengthof(arr) can work; the array size information
> has already been discarded.

He's proposing a new feature, right? There's no reason that the new 
feature couldn't require that the compiler *not* discard that 
information, and there's no reason that the new feature couldn't be 
defined to be allowed only when the user has provided that information.

> >>> It's certainly desirable to be able to obtain the size of an array
> >>> when the language knows it.
> >> 
> >> But in the case at hand the language _doesn't_ know it.
>
> A parameter cannot be of array type, so you can't ask about the length
> of a parameter.  A parameter *can* be of pointer-to-array type, so you
> can ask about the length of what a parameter points to.
> 
> The language *doesn't know* about the size of the array object
> corresponding to something that looks like an array parameter.  The
> length can vary from one call to another, and the length information is
> quietly discarded (unless you pass it explicitly as another argument).

Sure it does (in the example under discussion). It currently discards 
the size information, as you say, because it isn't needed, but it 
doesn't *have* to discard it, if a mechanism were provided to get it.

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

#1448

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

Nor did "fully qualified" have any meaning in this language, last I 
looked.  That's C++ speak.

I will ignore and snip all references to this imaginary entity from here on.

> which has most of the behaviors of an array.

Not more so than any other pointer would.  Which makes sense, since it 
_is_ a pointer.

>      True.  And here's the mess it creates, even for a fixed size array:
>
> typedef double mat4[4][4];
> void fn1(mat4 m0)
> {   mat4 m1;
>      size_t s0 = sizeof(m0);
>      size_t s1 = sizeof(m1);
>      printf("Size of m0 is %d.\nSize of m1 is %d", s0, s1);
> }
>
> Size of m0 is 4.
> Size of m1 is 128
>
> This is not good.

That's only a mess if you want it to be one.

>>> It's certainly desirable to be able to obtain the size of an array
>>> when the language knows it.
>>
>> But in the case at hand the language _doesn't_ know it.
>
>     Array size information is used for subscript calculations for
> multidimensional array parameters.

That only considers the size for the inner dimensions.  The one we're 
looking at here is the outermost dimension --- and that's neither used 
nor needed for that.

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

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

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

csiph-web