Bug 18 – int foo[0] accept -- what's its semantics?

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
PowerPC
OS
Mac OS X
Creation time
2006-03-05T18:30:00Z
Last change time
2015-06-09T05:15:04Z
Assigned to
ibuclaw
Creator
braddr

Comments

Comment #0 by braddr — 2006-03-05T18:30:55Z
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?
Comment #1 by bugzilla — 2006-03-10T00:46:25Z
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.
Comment #2 by braddr — 2006-03-10T01:15:27Z
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.
Comment #3 by bugzilla — 2006-04-24T20:03:34Z
Added additional documentation to www.digitalmars.com/d/arrays.html
Comment #4 by braddr — 2006-04-24T21:23:44Z
Moving this bug over to gdc since the segv is still there and needs to be resolved.
Comment #5 by smjg — 2006-05-09T09:59:36Z
"A static array with a dimension of 0 is allowed, but no space is allocated for it. It's useful as the last member of a variable length struct, or as the degenerate case of a template expansion." Still could be improved. If it's the degenerate case of a template expansion, then you'd want the bounds checking to be still active. If OTOH you're using it to make a variable length struct, then you'd want there to be no bounds checking ... unless the intention is to force the programmer to write array.ptr[42] instead of array[42]. So, are zero-length static arrays bounds-checked or not?
Comment #6 by braddr — 2006-11-25T15:08:12Z
Mass reassignment of gdc bugs from me to David.
Comment #7 by ibuclaw — 2010-08-11T11:59:10Z
I'll optimistically close this, as I cannot replicate the segv Brad mentioned on the most recent tip of GDC. However I am noting that this was raised against PPC - so if this still exists for that platform, do shout.