http://d.puremagic.com/issues/show_bug.cgi?id=2934
qian...@funkwerk-itk.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Comment #3 from qian...@funkwerk-itk.com 2009-05-05 02:46 -------
> 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.
I am fully agree with you. But before using ".dup" a string variable has
triple-state (null, empty or not empty). After adding a ".dup" to an empty
string, it might be reduced to two. This will break existing code, if defensive
copies of strings are made.
An example is as follows:
class test {
private char[] val;
char[] getVal() {
return val.dup; // make a defensive copy to avoid unexpected change from
outside
}
void setVal(char[] val) {
this.val = val.dup;
}
}
myTestObj.setVal("");
char[] s = myTestObj.getVal;
if (s is null) {
// do task 1
}
else if (s == "") {
// do task 2
}
else {
// do task 3
}
In this case, task 2 is expected to be performed. However task 1 will be
performed.
> 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.
Did you mean, that this is a feature request? I would like to regard the
inconsistency of the dup-effect as a defect.
--
