Jump to page: 1 24  
Page
Thread overview
Zero-length static array spec
Feb 01, 2015
Stefan Frijters
Feb 01, 2015
ketmar
Feb 01, 2015
Iain Buclaw
Feb 01, 2015
Stefan Frijters
Feb 01, 2015
H. S. Teoh
Feb 01, 2015
Iain Buclaw
Feb 01, 2015
Iain Buclaw
Feb 01, 2015
ketmar
Feb 01, 2015
H. S. Teoh
Feb 01, 2015
ketmar
Feb 06, 2015
David Nadlinger
Feb 06, 2015
ketmar
Feb 06, 2015
David Nadlinger
Feb 06, 2015
ketmar
Feb 06, 2015
Daniel Murphy
Feb 06, 2015
Iain Buclaw
Feb 06, 2015
David Nadlinger
Feb 06, 2015
Iain Buclaw
Feb 06, 2015
David Nadlinger
Feb 07, 2015
FG
Feb 07, 2015
Iain Buclaw
Feb 07, 2015
FG
Feb 07, 2015
Iain Buclaw
Feb 07, 2015
David Nadlinger
Feb 07, 2015
Iain Buclaw
Feb 07, 2015
David Nadlinger
Feb 08, 2015
Iain Buclaw
Feb 08, 2015
David Nadlinger
Feb 08, 2015
Iain Buclaw
Feb 08, 2015
Iain Buclaw
Feb 08, 2015
Brian Schott
Feb 07, 2015
Marc Schütz
Feb 26, 2015
kinke
Feb 27, 2015
Marc Schütz
Feb 06, 2015
David Nadlinger
February 01, 2015
So recently I ran into this discrepancy between the behaviour of dmd (and gdc) and ldc2:

void test(int[] data)
  in { assert(data, "data must be non-null."); }
  body { }

void main() {
  import std.stdio;
  int[1] data1;
  writeln(data1); // [0]
  test(data1); // Passes
  assert(data1.ptr !is null);
  int[0] data0;
  writeln(data0); // []
  test(data0); // Passes with dmd and gdc, fails with ldc2 (2.066.1)
  assert(data0.ptr !is null); // Passes with dmd and gdc, fails with ldc2
}

I reported this as an issue at https://github.com/ldc-developers/ldc/issues/831 and was asked to check for a more definite answer. So, in light of recent developments of trying to tighten up the D spec, does anyone have any insight what the correct behaviour should be, and can it be locked down in the spec?

Currently the D spec says [1]:

---

Static Arrays
int[3] s;
These are analogous to C arrays. Static arrays are distinguished by having a length fixed at compile time.

The total size of a static array cannot exceed 16Mb. A dynamic array should be used instead for such large arrays.

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.

Static arrays are value types. Unlike in C and D version 1, static arrays are passed to functions by value. Static arrays can also be returned by functions.

---

It does not seem to say whether a zero-length array should have a valid address or not.

Thoughts?

[1] http://dlang.org/arrays.html
February 01, 2015
On Sun, 01 Feb 2015 14:42:31 +0000, Stefan Frijters wrote:

> It does not seem to say whether a zero-length array should have a valid address or not.

i believe that zero-length array should not be `null`, as it's "infinitely small", yet not "non-existent". at least this is what my logic tells me.

February 01, 2015
On 1 February 2015 at 14:54, ketmar via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sun, 01 Feb 2015 14:42:31 +0000, Stefan Frijters wrote:
>
>> It does not seem to say whether a zero-length array should have a valid address or not.
>
> i believe that zero-length array should not be `null`, as it's "infinitely small", yet not "non-existent". at least this is what my logic tells me.

Infinitely small:
Smaller than the smallest thing ever and then some more. Much smaller
than that in fact, really amazingly insignificant, a totally
unimpressive size, real 'wow, that's small', time.  Infinitely small
is just so small that by comparison, smallness itself looks really
humongous.  Miniscule divided by meager divided by staggeringly
infinitesimal is the sort of concept we're trying to get across here.

:-)
February 01, 2015
On Sunday, 1 February 2015 at 14:54:37 UTC, ketmar wrote:
> On Sun, 01 Feb 2015 14:42:31 +0000, Stefan Frijters wrote:
>
>> It does not seem to say whether a zero-length array should have a valid
>> address or not.
>
> i believe that zero-length array should not be `null`, as it's
> "infinitely small", yet not "non-existent". at least this is what my
> logic tells me.

Fwiw, I would also like this to be the case, as to not have to handle any special cases when using int[N] templates and such.
February 01, 2015
On 1 February 2015 at 14:42, Stefan Frijters via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Static Arrays
> int[3] s;
> These are analogous to C arrays. Static arrays are distinguished by having a
> length fixed at compile time.
>
> The total size of a static array cannot exceed 16Mb. A dynamic array should be used instead for such large arrays.
>
> 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.
>
> Static arrays are value types. Unlike in C and D version 1, static arrays are passed to functions by value. Static arrays can also be returned by functions.
>
> ---
>
> It does not seem to say whether a zero-length array should have a valid address or not.
>
> Thoughts?
>

Regardless of size, a static array should always have an address on the stack.  Of course, dereferencing said address is undefined.

You can also consider it a require that although a zero-length static array may have an address, it doesn't take up any space either.

Consider:

int[0] data0;
int[1] data1;


Here, you could expect both data0 and data1 to have the same .ptr address, but data0.ptr == data1.ptr should not succeed either.
February 01, 2015
On Sun, 01 Feb 2015 15:34:39 +0000, Iain Buclaw via Digitalmars-d wrote:

> Regardless of size, a static array should always have an address on the stack.  Of course, dereferencing said address is undefined.
> 
> You can also consider it a require that although a zero-length static array may have an address, it doesn't take up any space either.
> 
> Consider:
> 
> int[0] data0;
> int[1] data1;
> 
> 
> Here, you could expect both data0 and data1 to have the same .ptr address, but data0.ptr == data1.ptr should not succeed either.

actually, `data0.ptr` can point anywhere (except 0 as null ;-), 'cause it's so small that it takes no room at all, so it doesn't matter where it will be placed. ;-)

February 01, 2015
On Sun, Feb 01, 2015 at 03:11:07PM +0000, Iain Buclaw via Digitalmars-d wrote: [...]
> Infinitely small:
> Smaller than the smallest thing ever and then some more. Much smaller
> than that in fact, really amazingly insignificant, a totally
> unimpressive size, real 'wow, that's small', time.  Infinitely small
> is just so small that by comparison, smallness itself looks really
> humongous.  Miniscule divided by meager divided by staggeringly
> infinitesimal is the sort of concept we're trying to get across here.
[...]

Wait wait wait... Miniscule *divided* by meager divided by staggeringly infinitesimal?! Wouldn't that be a non-standard number larger than any finite number?


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases.  He/She has prejudices. -- Gene Wirchenko
February 01, 2015
On Sun, Feb 01, 2015 at 03:46:15PM +0000, ketmar via Digitalmars-d wrote:
> On Sun, 01 Feb 2015 15:34:39 +0000, Iain Buclaw via Digitalmars-d wrote:
> 
> > Regardless of size, a static array should always have an address on the stack.  Of course, dereferencing said address is undefined.
> > 
> > You can also consider it a require that although a zero-length static array may have an address, it doesn't take up any space either.
> > 
> > Consider:
> > 
> > int[0] data0;
> > int[1] data1;
> > 
> > 
> > Here, you could expect both data0 and data1 to have the same .ptr address, but data0.ptr == data1.ptr should not succeed either.
> 
> actually, `data0.ptr` can point anywhere (except 0 as null ;-), 'cause it's so small that it takes no room at all, so it doesn't matter where it will be placed. ;-)

Actually, it *can* be null too, since it doesn't actually take up any space, so it would fit perfectly fine in nullspace (non-existent space) as well. :-P


T

-- 
IBM = I'll Buy Microsoft!
February 01, 2015
On Sun, 01 Feb 2015 07:50:08 -0800, H. S. Teoh via Digitalmars-d wrote:

>> actually, `data0.ptr` can point anywhere (except 0 as null ;-), 'cause it's so small that it takes no room at all, so it doesn't matter where it will be placed. ;-)
> 
> Actually, it *can* be null too, since it doesn't actually take up any space, so it would fit perfectly fine in nullspace (non-existent space) as well. :-P

then it will become non-existent too, as putting something to the place that doesn't exist turns that to non-existent. ;-)

February 01, 2015
On 1 February 2015 at 15:46, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sun, Feb 01, 2015 at 03:11:07PM +0000, Iain Buclaw via Digitalmars-d wrote: [...]
>> Infinitely small:
>> Smaller than the smallest thing ever and then some more. Much smaller
>> than that in fact, really amazingly insignificant, a totally
>> unimpressive size, real 'wow, that's small', time.  Infinitely small
>> is just so small that by comparison, smallness itself looks really
>> humongous.  Miniscule divided by meager divided by staggeringly
>> infinitesimal is the sort of concept we're trying to get across here.
> [...]
>
> Wait wait wait... Miniscule *divided* by meager divided by staggeringly infinitesimal?! Wouldn't that be a non-standard number larger than any finite number?
>

I was going for the opposite of "multiplied".  Let's ignore that decimal semantics exist for a moment. :)
« First   ‹ Prev
1 2 3 4