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

------- Comment #3 from  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
    void setVal(char[] val) {
      this.val = val.dup;

  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

> 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.


Reply via email to