Rainer Deyke wrote:
On 5/22/2010 23:16, Mike Parker wrote:
That's not the problem. The problem is this:
const(char)* toStringz(const(char)[] s);
There's no equivalent for:
char *toStringz(char[] s);
Hence the need to cast away const or use a wrapper for non-const char*
args.
There is no way to define this function with the correct semantics in D.
'toStringz' must append a null character to the string, therefore it
cannot return a pointer to the original string data in the general case.
If you pass the resulting string to a function that mutates it, then
the changes will not be reflected in the original string.
If you pass the resulting string to a function that does /not/ mutate
it, then that function should be defined to take a 'const char *'.
I understand that. But, ignoring the fact that toStringz in D1 seems to
have functioned perfectly fine for several years without a const return,
it doesn't change the fact that a C function call that accepts a char*
expects it to be null-terminated, regardless of what happens to it on
the other side.
And I would argue that it's unreasonable to expect the declarations of C
functions to be declared const-correct based on their usage. To my
knowledge, all of the C bindings for D to date either don't use const at
all (because they were created for D1) or use it according to the
declarations in the C headers. Which means there are numerous C
functions out there with non-const params that do not modify them.
Then there's the issue of compatibility between D1/D2. I've bound
several C libraries for D that need to support both D1/D2, Phobos/Tango.
Supporting const was one of the first headaches I encountered when
porting the original D1 bindings to D2. Finding that toStringz returned
a const string was a big surprise.
