toUtf8z bug and performance?

returning null (for a null array) is intended, but checking for an existing zero-terminator could certainly be added. Thanks!

What about a second version for returning always the valid ptr?

I'd rather not. A null input is a zero array pointer (and a zero length) ... that means a zero pointer is returned.

I had this case:

char[] res;
foreach( str; getRecords() ){
  res ~= str;
}
cfunction( toUtf8z( res ));

The cfunction segfaults for a NULL ptr. I think in the general case it is save to return a valid ptr to a null character. And there should be an explicit case to get null-ptr for a null d array.

toUtf8z vs. toUtf8zNull

So how would you write this code to work properly?
res would need to be initialized to a valid ptr and length zero.

char[] res = nullString; // can we have this in tango?
foreach( str; getRecords() ){
  res ~= str;
}
cfunction( toUtf8z( res ));

Now it would work, but it means the initialization needs to know about the later use in toUtf8z. Or I can do this:

char[] res;
foreach( str; getRecords() ){
  res ~= str;
}
char* ptr = toUtf8z( res );
cfunction( ptr ? ptr : nullString );

Extra variable declaration, yuck!

Or I need a workaround function in my app.

I think there should be no difference in handling a null intput and a zero length array input, because D does a null initialization.

Sorry Frank, this is application-specific behaviour. What if cfunction() expected and/or could deal with null as valid input? Other folks would (rightfully) complain that a null input should return a null output.

Besides, your example can be written without extra var decls:

char[] res;
foreach( str; getRecords() ){
  res ~= str;
}
cfunction(res.length ? toUtf8z(res) : "");

(In [2586]) fixes #649

added short-circuit to avoid appending multiple nulls

So there is one last question unanswered ...

Why not add the variation which offers to return always the valid ptr? char* toUtf8zPtr(char[] str)

I will stop bugging you with that, from now on. :)

toUtf8zNeverNullPtr!(char[])(str) ?

:)

Is this really useful? If that's a yes, I suppose we may include, but I'm currently reluctant.