toStringz or not toStringz

[Steven Schveighoffer]

On Tue, 12 Jul 2011 09:54:15 -0400, Regan Heath <regan at netmail.co.nz>  
wrote:

> On Fri, 08 Jul 2011 18:59:47 +0100, Walter Bright  
> <newshound2 at digitalmars.com> wrote:
>
>> On 7/8/2011 4:53 AM, Regan Heath wrote:
>>> On Fri, 08 Jul 2011 10:49:08 +0100, Walter Bright  
>>> <newshound2 at digitalmars.com>
>>> wrote:
>>>
>>>> On 7/8/2011 2:26 AM, Regan Heath wrote:
>>>>> Why can't we have the
>>>>> compiler call it automatically whenever we pass a string, or char[]  
>>>>> to an extern
>>>>> "C" function, where the parameter is defined as char*?
>>>>
>>>> Because char* in C does not necessarily mean "zero terminated string".
>>>
>>> Sure, but in many (most?) cases it does. And in those cases where it  
>>> doesn't you
>>> could argue ubyte* or byte* should have been used in the D extern "C"
>>> declaration instead. Plus, in those cases, worst case scenario, D  
>>> passes an
>>> extra \0 byte to those functions which either ignore it because they  
>>> were also
>>> passed a length, or expect a fixed sized structure, or .. I don't know  
>>> what as I
>>> can't imagine another case where char* would be used without it being  
>>> a "zero
>>> terminated string", or passing/knowing the length ahead of time.
>>
>> In the worst case, you're adding an extra memory allocation and  
>> function call overhead (that is hidden to the user, and not  
>> turn-off-able). This is not acceptable when interfacing to C.
>
> This worst case only happens when:
> 1. The extern "C" function takes a char* and is NOT expecting a "zero  
> terminated string".
> 2. The char[], string, etc being passed is a fixed length array, or a  
> slice which has no available space left for the \0.
>
> So, it's rare.  I would guess a less than 1% of cases for general  
> programming.

What if you expect the function is expecting to write to the buffer, and  
the compiler just made a copy of it?  Won't that be pretty surprising?

-Steve