www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - toStringz and predictability

reply Ben Hinkle <Ben_member pathlink.com> writes:
There's something about toStringz that has me uncomfortable. Consider this code:

import std.string;

int main() {
char* x;
uint b1;
char[4] y;
uint b2;
y[0] = 'a';
y[1] = 'b';
y[2] = 'c';
y[3] = 'd';
x = toStringz(y);
printf("x length is %d, ptr %p b1 %p b2 %p\n",strlen(x),x,&b1,&b2);
b1 = 0x11223344;
b2 = 0x11223344;
printf("x length is %d, ptr %p b1 %p b2 %p\n",strlen(x),x,&b1,&b2);
return 0;
}

Here's what it prints when I run it:
x length is 4, ptr 0xfefff870 b1 0xfefff86c b2 0xfefff874
x length is 17, ptr 0xfefff870 b1 0xfefff86c b2 0xfefff874

The reason why the length changed is that toStringz looks at one past the length
of the string to see if it is 0 and does nothing to the string if it is. But the
sample code then changes the byte past the string by touching a completely
different variable and so the toStringz result is "corrupted". I have toStringz
calls sprinkled through my code when I call C functions and now I'm starting to
get nervous about the lifespans of those strings and how to figure out if they
are valid or not. Thoughts? Walter, is there a guideline I should follow? The
most extreme one that comes to mind is "only call toStringz for strings that get
immediately copied".

-Ben
Jan 18 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:csj4hq$1cvi$1 digitaldaemon.com...
 The reason why the length changed is that toStringz looks at one past the

 of the string to see if it is 0 and does nothing to the string if it is.

 sample code then changes the byte past the string by touching a completely
 different variable and so the toStringz result is "corrupted". I have

 calls sprinkled through my code when I call C functions and now I'm

 get nervous about the lifespans of those strings and how to figure out if

 are valid or not. Thoughts? Walter, is there a guideline I should follow?

 most extreme one that comes to mind is "only call toStringz for strings

 immediately copied".

It's "COW" (Copy On Write) to the rescue. The idea is only modify a string that you know is unique. If you don't know it is unique, make a copy of it before modifying it. After the toStringz(), you're modifying the argument to toStringz() but there's another reference to that string that expects it to not change.
Jan 18 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <csjffu$1qtp$1 digitaldaemon.com>, Walter says...
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:csj4hq$1cvi$1 digitaldaemon.com...
 The reason why the length changed is that toStringz looks at one past the

 of the string to see if it is 0 and does nothing to the string if it is.

 sample code then changes the byte past the string by touching a completely
 different variable and so the toStringz result is "corrupted". I have

 calls sprinkled through my code when I call C functions and now I'm

 get nervous about the lifespans of those strings and how to figure out if

 are valid or not. Thoughts? Walter, is there a guideline I should follow?

 most extreme one that comes to mind is "only call toStringz for strings

 immediately copied".

It's "COW" (Copy On Write) to the rescue. The idea is only modify a string that you know is unique. If you don't know it is unique, make a copy of it before modifying it.

But the string doesn't necessarily own the byte after the string. It's a random piece of memory. Even if the string is living on the heap the byte one past the array can be changed at pretty much any time by anything. Modifying the byte following a string is different than modifying a string.
 After the toStringz(), you're modifying the argument to
 toStringz() [...]

actually I'm not. I'm modifying another variable.
Jan 18 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

 But the string doesn't necessarily own the byte after the string. It's a random
 piece of memory. Even if the string is living on the heap the byte one past the
 array can be changed at pretty much any time by anything. Modifying the byte
 following a string is different than modifying a string.

The bug is in std/string.d :
 	p = &string[0] + string.length;
 
 	// Peek past end of string[], if it's 0, no conversion necessary.
 	// Note that the compiler will put a 0 past the end of static
 	// strings, and the storage allocator will put a 0 past the end
 	// of newly allocated char[]'s.
 	if (*p == 0)
 	    return string;

Yes, it does work for string literals and for dynamic arrays... But it doesn't work for slices of pointers, or static arrays ? Unless there is a way to separate them, it should be avoided. (since with the pointers/statics, the byte after is off-limits) --anders
Jan 18 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
Yes, it does work for string literals and for dynamic arrays...

Actually it doesn't even work for dynamic arrays: import std.string; int main() { char* x; char[] y = new char[32]; y[] = 0; char[] z = new char[32]; z[] = 32; x = toStringz(z); printf("x length is %d\n",strlen(x)); y[] = 32; printf("x length is %d\n",strlen(x)); return 0; } outputs x length is 32 x length is 67 This is due to how the memory manager allocates memory. -Ben
Jan 18 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

Yes, it does work for string literals and for dynamic arrays...

Actually it doesn't even work for dynamic arrays:

Funny, I was just writing that :-) It breaks down for certain multiples of two. (16, 32, 64, 128, 256, 512, 1024, and so on) Sample test program:
 import std.string;
 void main()
 {
   for (int x = 15; x <= 17; x++)
   {
     char[] a = new char[x];
     char[] b = new char[x];
     char[] c = new char[x];
     a[0] = 0;
     b[0] = 0;
     c[0] = 0;
     printf("%d %p\n",a);
     printf("%d %p\n",b);
     printf("%d %p\n",c);
     char *p = &a[0] + a.length;
     if(*p != 0) printf("not 0\n"); else printf("is 0\n");
     for(int i = 0; i < b.length; i++)
       b[i] = 'A' + i;
     char *z = toStringz(b);
     for(int i = 0; i < a.length; i++)
       a[i] = 'X';
     for(int i = 0; i < c.length; i++)
       c[i] = 'X';
     printf("%s\n",z);
   }
 }

Prints:
 15 0xbf498fe0
 15 0xbf498fd0
 15 0xbf498fc0
 is 0
 ABCDEFGHIJKLMNO
 16 0xbf498fb0
 16 0xbf498fa0
 16 0xbf498f90
 not 0
 ABCDEFGHIJKLMNOPXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 17 0xbf497fa0
 17 0xbf497f80
 17 0xbf497f60
 is 0
 ABCDEFGHIJKLMNOPQ

Perhaps a bit contrived, but shows how it works... std.string.toStringz is broken. --anders
Jan 18 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:csjffu$1qtp$1 digitaldaemon.com...
 "Ben Hinkle" <Ben_member pathlink.com> wrote in message
 news:csj4hq$1cvi$1 digitaldaemon.com...
 The reason why the length changed is that toStringz looks at one past


 length
 of the string to see if it is 0 and does nothing to the string if it is.

 sample code then changes the byte past the string by touching a


 different variable and so the toStringz result is "corrupted". I have

 calls sprinkled through my code when I call C functions and now I'm

 get nervous about the lifespans of those strings and how to figure out


 they
 are valid or not. Thoughts? Walter, is there a guideline I should


 The
 most extreme one that comes to mind is "only call toStringz for strings

 immediately copied".

It's "COW" (Copy On Write) to the rescue. The idea is only modify a string that you know is unique. If you don't know it is unique, make a copy of it before modifying it. After the toStringz(), you're modifying the argument

 toStringz() but there's another reference to that string that expects it

 not change.

In case you need another example, I can imagine just the act of calling a function could corrupt a toStringz result. Suppose the char[] was stored on the stack and the last element of the array is at the very top of the stack and that the next item after the stack is zero (and that the stack grows up in memory). Then calling toStringz (also suppose it that call was inlined just for simplicity) wouldn't make a copy.but calling a function after that would push another stack frame which could potentially set a non-zero byte immediately following the array. That would corrupt the result of toStringz. I couldn't get this to happen on any machine I have around here but it depends on the stack architecture and how function calls work but the problem is still there for some architectures. So I have a suggestion. Have toStringz always copy if the array is on the stack. Have it never copy if the array is in the data segment (so literals behave as they do today) and have it check the GC capacity to ask the GC for control over the byte following the array (though the length of the array would be unchanged). To implement this toStringz would probably have to be moved out of std.string and into internal. If it copied everything except literals then I can see keeping it in std.string. Anyhow, I agree wth Anders that something should be done. -Ben
Jan 19 2005
parent reply parabolis <parabolis softhome.net> writes:
Ben Hinkle wrote:

 So I have a suggestion. Have toStringz always copy if the array is on the
 stack. Have it never copy if the array is in the data segment (so literals
 behave as they do today) and have it check the GC capacity to ask the GC for
 control over the byte following the array (though the length of the array
 would be unchanged). To implement this toStringz would probably have to be
 moved out of std.string and into internal. If it copied everything except
 literals then I can see keeping it in std.string. Anyhow, I agree wth Anders
 that something should be done.
 

Would this implementation work? ---------------------------------------------------------------- char* toStringzz(char[] str) { str.length++; str[length-1] = cast(char)0x00; return cast(char*)&str; } ---------------------------------------------------------------- That is to say is the array resizing implementation sufficient to determine whether str is dynamic or static on its own and if it is dynamic deal wisely with cases where incrementing length might be sufficient? Can you break toStringzz in any of the cases that toStringz breaks?
Jan 19 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"parabolis" <parabolis softhome.net> wrote in message
news:csmbbh$444$1 digitaldaemon.com...
 Ben Hinkle wrote:

 So I have a suggestion. Have toStringz always copy if the array is on


 stack. Have it never copy if the array is in the data segment (so


 behave as they do today) and have it check the GC capacity to ask the GC


 control over the byte following the array (though the length of the


 would be unchanged). To implement this toStringz would probably have to


 moved out of std.string and into internal. If it copied everything


 literals then I can see keeping it in std.string. Anyhow, I agree wth


 that something should be done.

Would this implementation work? ---------------------------------------------------------------- char* toStringzz(char[] str) { str.length++; str[length-1] = cast(char)0x00; return cast(char*)&str; } ---------------------------------------------------------------- That is to say is the array resizing implementation sufficient to determine whether str is dynamic or static on its own and if it is dynamic deal wisely with cases where incrementing length might be sufficient? Can you break toStringzz in any of the cases that toStringz breaks?

Nice idea. I think it's on the right track. I've cleaned it up a bit: char* toStringzz(char[] str) { str.length = str.length+1; str[length-1] = 0; return str.ptr; } Also it copies string literals. If there is an easy way to check if something is a string literal we can add that to your code and have a good solution, I think.
Jan 19 2005
next sibling parent reply Lukas Pinkowski <Lukas.Pinkowski web.de> writes:
Ben Hinkle wrote:
 Nice idea. I think it's on the right track. I've cleaned it up a bit:
 char* toStringzz(char[] str) {
     str.length = str.length+1;
     str[length-1] = 0;
     return str.ptr;
 }
 
 Also it copies string literals. If there is an easy way to check if
 something is a string literal we can add that to your code and have a good
 solution, I think.

Hm, doesn't initialize D uninitialized chars to 0 (here str[length-1]), so you can leave out the str[length-1] = 0; part? Thus better: char* toStringzz(char[] str) { str.length = str.length+1; return str.ptr; } But this actually alters the parameter (is this intended?) My version would be: char* toStringz( in char[] str ) { char[] new_str; new_str.length = str.length + 1; new_str[0 .. length-2] = str[0 .. length-1]; return &new_str[0]; } Creating a copy of the parameter, thus not changing it as you would think for in-parameters. I checked and it works for string literals, too.
Jan 19 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Lukas Pinkowski" <Lukas.Pinkowski web.de> wrote in message
news:csmfl4$a4c$1 digitaldaemon.com...
 Ben Hinkle wrote:
 Nice idea. I think it's on the right track. I've cleaned it up a bit:
 char* toStringzz(char[] str) {
     str.length = str.length+1;
     str[length-1] = 0;
     return str.ptr;
 }

 Also it copies string literals. If there is an easy way to check if
 something is a string literal we can add that to your code and have a


 solution, I think.

Hm, doesn't initialize D uninitialized chars to 0 (here str[length-1]), so you can leave out the str[length-1] = 0; part?

the initializer for char is 0xFF.
 Thus better:

 char* toStringzz(char[] str) {
     str.length = str.length+1;
     return str.ptr;
 }

 But this actually alters the parameter (is this intended?)

an array is a pointer to data and a length. Those are passed by value, so changing the length does not change the original string passed to the function.
 My version would be:

 char* toStringz( in char[] str )
 {
   char[] new_str;
   new_str.length = str.length + 1;
   new_str[0 .. length-2] = str[0 .. length-1];
   return &new_str[0];
 }

 Creating a copy of the parameter, thus not changing it as you would think
 for in-parameters. I checked and it works for string literals, too.

watch out for the case when new_str.ptr is str.ptr since I expect the array copy will error if you try to copy overlapping arrays.
Jan 19 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
(Actually, I refer here to several examples in this thread.)

char* toStringzz(char[] str) {
    str.length = str.length+1;
    str[length-1] = 0;
    return str.ptr;
}



What bothers me is, if a string gets repeatedly passed, say, between a library and the main program, and the library functions pass the string on to the OS or another library, every time using toStringz -- then what keeps the string from growing at each iteration? Finally we end up with a (possibly short) string with a lot of zeros at the end. It seems harmless at first glance, but what if later this kind of strings are concatenated (in D code) and passed on to a C-written parser? It would see a lot of "empty strings" between real data. Or am I missing something? In the same manner, should toStringz guarantee a valid C string? I.e. no internal zeros? At the _very least_ in the non-release build! ---- The name toStringz is misleading. Since the only use for it is to make strings edible for C code, it should be renamed toStringC. Normally, if a programmer _wants_ to slap a zero at the end, he'd use ~, wouldn't he. Misnomers like this introduce parallax, and in this case so subtle that we don't even notice. And that's where it _really_ counts!
Jan 24 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 It seems harmless at first glance, but what if later this kind of 
 strings are concatenated (in D code) and passed on to a C-written 
 parser? It would see a lot of "empty strings" between real data.
 
 Or am I missing something?

It would probably be easier to remove the hack altogether and just copy?
     body
     {
 	if (string.length == 0)
 	    return "";
 
 	// Need to make a copy
 	char[] copy = new char[string.length + 1];
 	copy[0..string.length] = string;
 	copy[string.length] = 0;
 	return copy;
     }

Isn't that just what "string.length = string.length + 1" does, anyway ? It would be neat if it could be optimized for string literals, but not at the expense of making the whole function instable? (like it is now)
 In the same manner, should toStringz guarantee a valid C string? I.e. no 
 internal zeros? At the _very least_ in the non-release build!

The contract for toStringz specifies that the char[] is *without* '\0':
     in
     {
 	if (string)
 	{
 	    // No embedded 0's
 	    for (uint i = 0; i < string.length; i++)
 		assert(string[i] != 0);
 	}
     }
     out (result)
     {
 	if (result)
 	{   assert(strlen(result) == string.length);
 	    assert(memcmp(result, string, string.length) == 0);
 	}
     }

It also (implicitly) returns a "" string, for an input param of null.
 The name toStringz is misleading. Since the only use for it is to make 
 strings edible for C code, it should be renamed toStringC. Normally, if 
 a programmer _wants_ to slap a zero at the end, he'd use ~, wouldn't he.

It converts a char[], to a zero-terminated char*. No "C" about that ?? (I'm not sure why it doesn't just 'return (string ~ "\0");', anyone ?) ==> body { return ((string.length == 0) ? "" : string ~ "\0"); } Besides, most of the C functions does not accept UTF-8 input anyway... To be usable from regular C, it would need to be converted to byte* ? (and that would most likely involve charset encoding conversion too) --anders
Jan 24 2005
prev sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
another version:

char* toStringzz(char[] str) {
    str ~= 0;
    return str.ptr;
}
Jan 19 2005
prev sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <csjffu$1qtp$1 digitaldaemon.com>, Walter says...
"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:csj4hq$1cvi$1 digitaldaemon.com...
 The reason why the length changed is that toStringz looks at one past the

 of the string to see if it is 0 and does nothing to the string if it is.

 sample code then changes the byte past the string by touching a completely
 different variable and so the toStringz result is "corrupted". I have

 calls sprinkled through my code when I call C functions and now I'm

 get nervous about the lifespans of those strings and how to figure out if

 are valid or not. Thoughts? Walter, is there a guideline I should follow?

 most extreme one that comes to mind is "only call toStringz for strings

 immediately copied".

It's "COW" (Copy On Write) to the rescue. The idea is only modify a string that you know is unique. If you don't know it is unique, make a copy of it before modifying it. After the toStringz(), you're modifying the argument to toStringz() but there's another reference to that string that expects it to not change.

ok, one last try. Walter, I can't tell if you still think this counts as COW. So let me boil it down to a question. Given the code char[1] str; char* cstr = toStringz(str); ubyte x = 1; what is strlen(cstr)? I claim the answer is compiler dependent and depends on if the compiler stuck the storage location for x immediately following str. Sure running the code doesn't have a problem due to word alignment etc but following the language definition and the definition of toStringz the strlen is unknown. -Ben
Jan 20 2005
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

 There's something about toStringz that has me uncomfortable. Consider this
code:
 
 import std.string;
 
 int main() {
 char* x;
 uint b1;
 char[4] y;
 uint b2;
 y[0] = 'a';
 y[1] = 'b';
 y[2] = 'c';
 y[3] = 'd';
 x = toStringz(y);
 printf("x length is %d, ptr %p b1 %p b2 %p\n",strlen(x),x,&b1,&b2);
 b1 = 0x11223344;
 b2 = 0x11223344;
 printf("x length is %d, ptr %p b1 %p b2 %p\n",strlen(x),x,&b1,&b2);
 return 0;
 }
 
 Here's what it prints when I run it:
 x length is 4, ptr 0xfefff870 b1 0xfefff86c b2 0xfefff874
 x length is 17, ptr 0xfefff870 b1 0xfefff86c b2 0xfefff874

That's dependent on the compiler, and the alignment: GDC Linux: x length is 4, ptr 0xbff772b8 b1 0xbff772bc b2 0xbff772b0 x length is 25, ptr 0xbff772b8 b1 0xbff772bc b2 0xbff772b0 GDC Mac OS X: x length is 4, ptr 0xbffffaa0 b1 0xbffffa9c b2 0xbffffaa8 x length is 4, ptr 0xbffffaa0 b1 0xbffffa9c b2 0xbffffaa8 But why are you calling toStringz on a simple (char*), without having it properly NUL-terminated at the end ? If you change the code to : char[] y = new char[4]; Then it prints: x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c A more interesting question is why : x = toStringz(y[0..4]); does *not* make a copy of the converted pointer-to-characters, just because the next byte in memory happens to be a NUL char? (ie. it works if first byte of "b1" is 42, but not if it's 0) Having to use x = toStringz(y[0..4].dup); just because of this little "optimization" feature is not exactly a given... There should probably be a small warning printed about using toStringz on slices (since it works with literals and arrays) But that it fails on pointers and static arrays is not surprising? --anders PS. If you add a -O on Mac OS X, then it prints "12" instead. So just because it printed 4 above doesn't mean it works.
Jan 18 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
That's dependent on the compiler, and the alignment:

GDC Linux:
x length is 4, ptr 0xbff772b8 b1 0xbff772bc b2 0xbff772b0
x length is 25, ptr 0xbff772b8 b1 0xbff772bc b2 0xbff772b0

GDC Mac OS X:
x length is 4, ptr 0xbffffaa0 b1 0xbffffa9c b2 0xbffffaa8
x length is 4, ptr 0xbffffaa0 b1 0xbffffa9c b2 0xbffffaa8

even more interesting...
But why are you calling toStringz on a simple (char*),
without having it properly NUL-terminated at the end ?

The point of toStringz is to make a D string null terminated.
If you change the code to : char[] y = new char[4];

Then it prints:
x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c
x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c

That's becaseu the "new" allocates space on the heap and so it has nothing to do with b1 and b2 after that. To corrupt the string on the heap you'l have to wait until something else gets allocated right after that string and then assign something to the first byte.
A more interesting question is why : x = toStringz(y[0..4]);
does *not* make a copy of the converted pointer-to-characters,
just because the next byte in memory happens to be a NUL char?
(ie. it works if first byte of "b1" is 42, but not if it's 0)

Having to use x = toStringz(y[0..4].dup); just because of
this little "optimization" feature is not exactly a given...
There should probably be a small warning printed about using
toStringz on slices (since it works with literals and arrays)

I'm starting to think the only safe usage of toStringz is on arrays where you can guarantee the byte after the string is owned by the string - which includes literals and maybe some other special cases.
But that it fails on pointers and static arrays is not surprising?

--anders

PS. If you add a -O on Mac OS X, then it prints "12" instead.
     So just because it printed 4 above doesn't mean it works.

ok.
Jan 18 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

But why are you calling toStringz on a simple (char*),
without having it properly NUL-terminated at the end ?

The point of toStringz is to make a D string null terminated.

Never mind, I was thinking in C (just because it is implemented that way), forget that D treats static arrays as having lengths... --anders
Jan 18 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

If you change the code to : char[] y = new char[4];

Then it prints:
x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c
x length is 4, ptr 0xbf429fe0 b1 0xbff3c758 b2 0xbff3c74c

That's becaseu the "new" allocates space on the heap and so it has nothing to do with b1 and b2 after that. To corrupt the string on the heap you'l have to wait until something else gets allocated right after that string and then assign something to the first byte.

Right, I think I only got lucky because how it allocates memory... I couldn't find any traces of "the storage allocator will put a 0 past the end of newly allocated char[]'s", so that must be just DMC. In fact, I'm not sure that even DMD does it ? This test program:
 void main()
 {
   for (int i = 1; i <= 1024; i++)
   {
     char[] a = new char[i];
     char *p = &a[0] + a.length;
     if(*p != 0) printf("%d\n",i);
   }
 }

Prints out 16,32,64,128,256,512,1024 for *all* the various D compilers. So that toStringz peeks beyond the length of the array is clearly a bug! Perhaps if it could tell that the argument is a string literal ? Naah... --anders
Jan 18 2005
prev sibling parent reply parabolis <parabolis softhome.net> writes:
Ben Hinkle wrote:
 There's something about toStringz that has me uncomfortable. Consider this
code:

There is something else that you should be uncomfortable about - the domains of C strings and D strings are not the same. The toStringz function is so named because C strings are 'Z'ero (or null) terminated. That implies they cannot contain a null character yet D strings have no such silly limitations. So the toStringz function should probably look like this: ---------------------------------------------------------------- char* toStringz(char[] dStr) { char[] cStr = new char[dStr.length+1]; foreach(int i, char dChar; dStr) { if(!(cStr[i] = dChar)) throw new Exception("Null char"); } return &cStr; ---------------------------------------------------------------- Now seems like a great time for plugging the unless/until feature of Perl as being nice in this context allowing: unless(cStr[i] = dChar) throw new Exception("Null char");
Jan 19 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"parabolis" <parabolis softhome.net> wrote in message 
news:csmiqa$edp$1 digitaldaemon.com...
 Ben Hinkle wrote:
 There's something about toStringz that has me uncomfortable. Consider 
 this code:

There is something else that you should be uncomfortable about - the domains of C strings and D strings are not the same. The toStringz function is so named because C strings are 'Z'ero (or null) terminated. That implies they cannot contain a null character yet D strings have no such silly limitations.

I hate to disagree but.. that doesn't bother me. I don't see anything wrong with ignoring interior zeros. toStringz just makes sure it is zero-terminated - not that that aren't any internal zeros. [snip]
Jan 19 2005
parent parabolis <parabolis softhome.net> writes:
Ben Hinkle wrote:
 "parabolis" <parabolis softhome.net> wrote in message 
 news:csmiqa$edp$1 digitaldaemon.com...
 
Ben Hinkle wrote:

There's something about toStringz that has me uncomfortable. Consider 
this code:

There is something else that you should be uncomfortable about - the domains of C strings and D strings are not the same. The toStringz function is so named because C strings are 'Z'ero (or null) terminated. That implies they cannot contain a null character yet D strings have no such silly limitations.

I hate to disagree but.. that doesn't bother me. I don't see anything wrong with ignoring interior zeros. toStringz just makes sure it is zero-terminated - not that that aren't any internal zeros. [snip]

char* toStringz(char[] dStr, bit ignoreNullsInString = true) ----------------------------------------------------------------
Jan 19 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"parabolis" <parabolis softhome.net> wrote in message
news:csmiqa$edp$1 digitaldaemon.com...
 Ben Hinkle wrote:
 There's something about toStringz that has me uncomfortable. Consider this
code:

There is something else that you should be uncomfortable about - the domains of C strings and D strings are not the same. The toStringz function is so named because C strings are 'Z'ero (or null) terminated. That implies they cannot contain a null character yet D strings have no such silly limitations. So the toStringz function should probably look like this: ---------------------------------------------------------------- char* toStringz(char[] dStr) { char[] cStr = new char[dStr.length+1]; foreach(int i, char dChar; dStr) { if(!(cStr[i] = dChar)) throw new Exception("Null char"); } return &cStr; ---------------------------------------------------------------- Now seems like a great time for plugging the unless/until feature of Perl as being nice in this context allowing: unless(cStr[i] = dChar) throw new Exception("Null char");

Has there been debate about unless/until? If so, count me on the list of 'wanting'. :-)
Jan 21 2005
parent parabolis <parabolis softhome.net> writes:
Matthew wrote:
 "parabolis" <parabolis softhome.net> wrote in message
news:csmiqa$edp$1 digitaldaemon.com...
 
----------------------------------------------------------------
char* toStringz(char[] dStr) {
  char[] cStr = new char[dStr.length+1];
  foreach(int i, char dChar; dStr) {
    if(!(cStr[i] = dChar)) throw new Exception("Null char");
  }
  return &cStr;
----------------------------------------------------------------

Now seems like a great time for plugging the unless/until feature of Perl as
being nice in this context allowing:

  unless(cStr[i] = dChar) throw new Exception("Null char");

Has there been debate about unless/until? If so, count me on the list of 'wanting'. :-)

Yes back around the time the digitalmars.d newsgroup started: http://www.digitalmars.com/d/archives/digitalmars/D/1714.html Walter wrote:
"Brian Hammond" <d at brianhammond dot comBrian_member xx 
pathlink.com> wrote
in message news:c8lmu2$vdm$1 xx digitaldaemon.com...
 I really like the unless because it reads so well.

 "do this unless this is true"

That just seems backwards to me <g>. I like things to execute forwards, not backwards.

However Walter's response was long before "is" replaced "===" and so I think it at least deserves another consideration as Perl's unless construct would give us "unless(A is null)" instead of the akward and much maligned "if(!(A is null))".
Jan 21 2005