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, and 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?

"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,
and
> 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 "".

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,
> and
> > 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 "".

> 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
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.

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
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,
> > and
> > > 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 "".
>
>

"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
the
> > compiler has an opportunity to see if the parameter passed in is always
> 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 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.

"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
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
> > 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
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.

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

"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,
and
> 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.

"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,
> and
> > expects a non-null char[] to be passed.
>
> I disagree. string.toStringz() works correctly when passed a null string
(it
> returns "").

My mistake. Strike one for the bleary eyed monster.

> > 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.

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?

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:brtikj$24oo$1@digitaldaemon.com...
> 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?

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>.

> > 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?
>
> 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 ...