On Feb 23, 3:36am, Greywolf wrote:
}
} After some courage and some digging, I finally found out what's
} breaking with SHAREDSTRINGS. It appears that xstr produces output
} which is obsolete -- or at least gcc 3.3.1 does not want to play
} well with it.
More like just plain broken.
} The other problem is that of the semantic difference between
}
} static char *foo = (something);
}
} and
}
} static char bar[] = (something);
}
} The former can have either a string literal or a reference given to it as
The string literal is a const which can't be changed.
} an rvalue, while the latter is restricted to a string literal only --
In this case, the string literal is only an initialiser for the
array and can be changed.
} statements of the form (given "extern char _xstr[];")
}
} static char bar[] = (&_xstr[99]);
}
} are not considered valid input to gcc.
Not surprising since an array is not a pointer.
} I see the following solutions to the second problem:
}
} 1. Obsolete xstr. I'm not sure if this is desirable or not;
Probably not, but it does need to be taught the C language.
} 2. Update xstr to either leave the RHS of static char [] alone or
} convert it to static char *;
Absolutely not! An array is not a pointer! They have different
semantics and blindly converting between them could really screw up a
program.
} 3. Update all sources to use static char *foo instead of static char foo[];
No, they have different uses.
} 4. Update all sources to use
}
} #ifdef __xstr__
} static char *foo
} #else
} static char foo[]
} #endif
} = "initialiser";
No, this would horribly complicate a program.
} Questions? Comments? Where do we go from here?
The only acceptable thing is to collapse string constants, but to
leave array initialisers alone. String constants are allowed to live
in read-only storage and thus aren't allowed to be change; however, the
contents of arrays can be changed.
}-- End of excerpt from Greywolf