Re: [PHP4BETA] cvs: /php4/ext/standard string.c php3_string.h

> the length is calculated from strlen() only when length=0 is > passed and it is the VERY SAME behaviour as the old > php_addslashes worked!!! (see that > emalloc((length?length:(length=strlen(str))).... stuff (!!)) Yes, you are right, so there is no need to shout. > > In the case a non-NUL terminated string has a length of 0, > > php_addslashes will segfault. Please revert this change. > should I revert it or just make it work when length=0? No, just leave it as it is. I have overlooked the previous strlen and I was just worried about backwards compatibility. > > I don't understand that change. "\000" is NUL and "0" twice. > > Does that make sense? The old behaviour has worked for > > everyone for years. > "\000" isn't null and 00 twice, it's NUL alone. > imagine, somebody has string "foo\0"."12bar", (66 6f 6f 00 > 31 32 62 61 72 in hex) and he addslashes(), the old version > would rewrite it to "foo\012bar", which isn't right, since > after stripslash()ing, it's (66 6f 6f 0a 62 61 72). I'll > rewrite it so it adds all three 0's only when a valid octal > digit follows... Ah, now I see what you mean. The problem is that the SQL92 standard (at least) does not define octal representations for use in SQL queries. If stripslashes behaves that way, it's broken. Look at the output of the following script: $m = "foo\0"."12bar"; $n = addslashes($m); $o = stripslashes($n); echo strlen($m).",".strlen($n).",".strlen($o)."\n"; echo "$m\n$n\n$o\n"; Output: 9,10,9 foo12bar foo\012bar foo12bar So, that seems pretty correct. Now, with your changes applied, the output looks like 9,12,11 foo12bar foo\00012bar foo0012bar which is obviously incorrect. -- Regards, Sascha Schumann Consultant