On 05/23/2010 04:47 AM, Pelle wrote:
On 05/23/2010 10:14 AM, Mike Parker wrote:
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.
I do them according to the C headers, and the constness is almost always
correct. Otherwise, it's a bug in the C headers!
Yes. My experience with C headers is that they're always careful about
inserting const for read-only pointer parameters.
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.
It should probably be inout(char)* toStringz(inout(char)[]), or
something like that.
It could, but what C functions output to a zero-terminated char*? I can
only think of unsafe ones, such as strcat() and gets(). Both are
inherently unsafe.
Andrei
