http://d.puremagic.com/bugzilla/show_bug.cgi?id=18

           Summary: int foo[0] accept -- what's its semantics?
           Product: D
           Version: 0.148
          Platform: Macintosh
               URL: http://www.digitalmars.com/drn-
                    bin/wwwnews?digitalmars.D.bugs/6444
        OS/Version: Mac OS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: walter@digitalmars.com
        ReportedBy: braddr@puremagic.com


void main() {
    int foo[0];
}

dmd 0.148 accepts this gdc 0.17 and my 0.18 work in progress both segv off in gcc land where it's assumed that variables passed into the middle end all have space associated with them.  What are the right semantics for this situation? I can fix gdc's interaction with the gcc internals, but I want to make sure I understand what it really means first.

Pushing the code a little:
     1  void main(){
     2      int i[0];
     3      int *j = &i;
     4      int *k = &(i[0]);
     5      return 0;
     6  }
$ dmd -g -c /tmp/junk.d
/tmp/junk.d(3): cannot implicitly convert expression (& i) of type int[0]* to
int*
/tmp/junk.d(4): array index [0] is outside array bounds [0 .. 0]
/tmp/junk.d(4): array index 0 is out of bounds [0..0]

So.. a 0 length array isn't terribly useable, which is good and a sign that it probably shouldn't be accepted.  However, see D.bugs/6444 for some more thoughts, specificaly as relates to empty strings.  At least with strings the size isn't 0 due to the length byte or null terminator depending on what type of string we're talking about, right?

So.. what is this: ice-on-valid or ice-on-invalid on the gdc side and potentially accepts-invalid on the dmd side?


-- 

> void main() {
>     int foo[0];
> }
>
> dmd 0.148 accepts this gdc 0.17 and my 0.18 work in progress both segv off in
> gcc land where it's assumed that variables passed into the middle end all have
> space associated with them.  What are the right semantics for this situation?

I'd like it to be allowed and completely disable bounds checking on that array, so that the old C trick can work: putting an array as the last field in a struct so that extra memory can be allocated after the struct to add more elements to the array at runtime. To further support this, 'new' for structs could be overloaded to take a parameter specifying how many elements are to be allocated for that last array field, for example:

struct Foo
{
   char* bar; // GC should know about this.
   int[0] baz; // Actual number of elements specified in new().
}
   ...
Foo* f = new(3) Foo; // Allocates 3 ints for Foo.baz for this instance.

Chris Miller wrote:
>> void main() {
>>     int foo[0];
>> }
>>
>> dmd 0.148 accepts this gdc 0.17 and my 0.18 work in progress both segv off in gcc land where it's assumed that variables passed into the middle end all have space associated with them. What are the
>> right semantics for this situation?
> 
> I'd like it to be allowed and completely disable bounds checking on that array, so that the old C trick can work: putting an array as the last field in a struct so that extra memory can be allocated after the struct to add more elements to the array at runtime.
<snip>

Is this to support a legacy API, or what?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

http://d.puremagic.com/bugzilla/show_bug.cgi?id=18


walter@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from walter@digitalmars.com  2006-03-10 00:46 -------
I've found 0 length arrays useful when building variable length structs.
Standard C doesn't allow it, but it's a common extension.
I say leave it in <g>.
It can be made to work in gcc by having locals with 0 length just get allocated
1 byte anyway.


-- 

http://d.puremagic.com/bugzilla/show_bug.cgi?id=18


braddr@puremagic.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
          Component|DMD                         |www.digitalmars.com
         Resolution|INVALID                     |




------- Comment #2 from braddr@puremagic.com  2006-03-10 01:15 -------
The semantics of a 0 length array needs to be well documented here:

    http://www.digitalmars.com/d/arrays.html

Even with the goal of supporting variable structs, the static bounds checking that's done (see the bounds errors in the original description), I'm not sure how usable it is right now.

I can certainly make gdc internally allocate it as if it was int[1], but that's not what this entry is about.  It's to clarify/define the exact behaviors.


-- 

http://d.puremagic.com/bugzilla/show_bug.cgi?id=18


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




------- Comment #3 from bugzilla@digitalmars.com  2006-04-24 20:03 -------
Added additional documentation to www.digitalmars.com/d/arrays.html


--