On Mon, 04 May 2009 16:56:49 -0400, Derek Parnell <de...@psych.ward> wrote:

On Mon, 4 May 2009 17:44:56 +0000 (UTC), d-bugm...@puremagic.com wrote:


schvei...@yahoo.com changed:

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

------- Comment #2 from schvei...@yahoo.com  2009-05-04 12:45 -------
From posts in the newsgroup, I've determined that this bug is invalid:

1. Duplicating an empty array should always return a null array. Otherwise, you'd have to allocate space to store 0 data bytes in order for the result to
be non-null.

2. String literals have a null character implicitly appended to them by the compiler. This is done to ease calling c functions. So a string literal's
pointer cannot be null, since it has to point to a static zero byte.

The spec identifies specifically item 2 here:

see the section describing "C's printf and Strings"

I could not find a reference for item 1, but I remember reading something about it. Regardless of it is identified specifically in the spec or not, it is not a bug, as the alternative would be to allocate blocks for 0-sized arrays.

Huh??? Duplicating something should give one a duplicate.

I do not think that this is an invalid bug.

Ok, so duplicating an empty array causes memory to be allocated - so what!
I asked for a duplicate so give me a duplicate, please.

To me, the "no surprise" path is simple. Duplicating an empty array should return an empty array. Duplicating a null array should return a null array.

Is that not intuitive?

what's not intuitive is comparing an array (which is a struct) to null.

char[] arr1 = "";
char[] arr2 = null;

assert(arr1 == arr2); // OK
assert(arr1 == null); // FAIL

I'd say that comparing an array to null should always succeed if the array is empty, but I guess some people may use the fact that the pointer is not null in an empty array. I definitely don't want the runtime to allocate blocks of data when requested to allocate 0 bytes.

In any case, this bug is not valid, because the compiler acts as specified by the spec.

I never compare arrays to null if I can remember, I always check the length instead, which is consistent for both null and empty arrays.


Reply via email to