www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Bug 18] New: int foo[0] accept -- what's its semantics?

reply d-bugmail puremagic.com writes:
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?


-- 
Mar 05 2006
next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
 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.
Mar 05 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.

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.
Mar 06 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Mar 09 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.


-- 
Mar 09 2006
prev sibling parent d-bugmail puremagic.com writes:
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


-- 
Apr 24 2006