Digital Mars - D - toStringz

↑ ↓ ← → "Vathix" <vathix dprogramming.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,


 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions working
 with null array (and other type) references?


I'd say a char[] that is actually null (s === null I think) should return
null, but if it's just 0 length, it should be "".

Dec 18 2003

↑ ↓ ← → "Sean L. Palmer" <palmer.sean verizon.net> writes:

What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
cycles over the entire execution, surely that's worth it!  ;)

((I'm joking.  I agree with Vathix.))

The nice thing about D is, that library functions can be inlined, and the
compiler has an opportunity to see if the parameter passed in is always null
or not, and eliminate the inappropriate cases.

Sean

"Vathix" <vathix dprogramming.com> wrote in message
news:brsn7u$q97$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,


 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions




 with null array (and other type) references?


 I'd say a char[] that is actually null (s === null I think) should return
 null, but if it's just 0 length, it should be "".

Dec 18 2003

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))


But it's not a joke. If we make library functions null-tolerant we may be
promoting the culture that Borland did by making their str??? functions
null-tolerant, which ...

 The nice thing about D is, that library functions can be inlined, and the
 compiler has an opportunity to see if the parameter passed in is always


 or not, and eliminate the inappropriate cases.


... leads to an overall loss of efficiency, since the compiler will be
unable to deduce all cases.

The less aesthetically appealing, but probably better, alternative is to
have different shims to be null-tolerant. (I refer the honourable gentleman
to the sidebar
http://www.cuj.com/documents/s=8681/cuj0308wilson/cuj0308wilson_sb4.htm from
my oft-touted "Generalized String Manipulation ..." article.)

I'd be interested in your further thoughts on this.

Matthew

 Sean

 "Vathix" <vathix dprogramming.com> wrote in message
 news:brsn7u$q97$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed






 null char[]. However, I can see that it might also be good to return






 What is scary is that the current implementation appears to do






 and
 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions




 with null array (and other type) references?


 I'd say a char[] that is actually null (s === null I think) should




 null, but if it's just 0 length, it should be "".

Dec 18 2003

↑ ↓ ← → "Vathix" <vathix dprogramming.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brt1d3$1ab7$1 digitaldaemon.com...
 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))


 But it's not a joke. If we make library functions null-tolerant we may be
 promoting the culture that Borland did by making their str??? functions
 null-tolerant, which ...

 The nice thing about D is, that library functions can be inlined, and




 compiler has an opportunity to see if the parameter passed in is always


 or not, and eliminate the inappropriate cases.


 ... leads to an overall loss of efficiency, since the compiler will be
 unable to deduce all cases.


I fail to see the problem. In D strings, null[0 .. 0] is just like "" and
won't cause a problem. The issue is with C strings, which shouldn't be used
too often. I solve this by doing  s = toStringz(s)[0 .. s.length] if I know
I'm going to be using a particular string a lot with C. Then I can use s
with functions that expect C or D strings.

Dec 18 2003

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

"Vathix" <vathix dprogramming.com> wrote in message
news:brt8ga$1lij$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brt1d3$1ab7$1 digitaldaemon.com...
 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10






 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))


 But it's not a joke. If we make library functions null-tolerant we may




 promoting the culture that Borland did by making their str??? functions
 null-tolerant, which ...

 The nice thing about D is, that library functions can be inlined, and




 compiler has an opportunity to see if the parameter passed in is






 null
 or not, and eliminate the inappropriate cases.


 ... leads to an overall loss of efficiency, since the compiler will be
 unable to deduce all cases.


 I fail to see the problem. In D strings, null[0 .. 0] is just like "" and
 won't cause a problem. The issue is with C strings, which shouldn't be


 too often. I solve this by doing  s = toStringz(s)[0 .. s.length] if I


 I'm going to be using a particular string a lot with C. Then I can use s
 with functions that expect C or D strings.


I don't really understand what you're saying there, I'm afraid. I'm not sure
you're addressing my issue.

I have a C function that either wants a file name, or it wants a null
(string) pointer. I call this function via a private static helper (to
provide exceptions if the C func fails) from within a couple of
constructors, two of which pass a (non-null) D string for the filename, and
the third passes a null.

In the D helper function I want to translate the potentially null D string
into either a null-terminated C string, or a null (C) string pointer.

Hence,

static void helper(char[] dstr)
{
  char *cstr = (null === dtr) ? null : toStringz(dstr);

  cfunc(cstr, . .. );
}

My point was whether toStringz() should be able to work with null D
strings - which it currently does _not_ - or whether we should be forced to
use the idiom shown in the code above.

I then suggested (rather ineptly, I admit), that the "null"-handling of such
helper functions should not be implicit, but rather in the form of a
separate function, perhaps call toStringzNull, as in

char *toStringz(char[] dstr)
{
  assert(null !== dstr); // This current does not exist!

  . . . // the rest of the current implementation
}

char *toStringzNull(char[] dstr)
{
  return (null === dstr) ? null : toStringz(dstr)
}

That way, we don't get into a Borland-like mindset whereby a null string is
the same as an empty string - which it most certainly is not - and we don't
infect all code with tests that 95% of it does not need. We are D, after
all, not Java! =P

Walter, any thoughts?

Matthew

Dec 18 2003

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,


 expects a non-null char[] to be passed.


I disagree. string.toStringz() works correctly when passed a null string (it
returns "").

 What're everyone's thoughts on a best policy for library-functions working
 with null array (and other type) references?


A null array has a .length property of 0. There should be no problem at all,
since a 0 length array and a NULL array have the same representation.

Dec 18 2003

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

"Walter" <walter digitalmars.com> wrote in message
news:brth37$22f3$2 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,


 expects a non-null char[] to be passed.


 I disagree. string.toStringz() works correctly when passed a null string


 returns "").


My mistake. Strike one for the bleary eyed monster.

 What're everyone's thoughts on a best policy for library-functions




 with null array (and other type) references?


 A null array has a .length property of 0. There should be no problem at


 since a 0 length array and a NULL array have the same representation.


That's good. That can be transferred to all manner of things. :)

That's going to have a cost, though, for each array access, since there'll
be checks for every .length access. You deliberately chose safety first
here, then?

Dec 18 2003

↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:

 That's going to have a cost, though, for each array access, since




 be checks for every .length access. You deliberately chose safety first
 here, then?


 I don't see how this is any extra cost. It's just normal array bounds
 checking, which can be turned on or off <g>.


I think I'm forgetting that arrays themselves (i.e. the len+ptr structures)
are passed by value.

Blonde moment ...

Dec 18 2003