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

From: Date: Sun, 05 Sep 1999 12:13:44 +0000
Subject: Re: [PHP4BETA] cvs: /php4/ext/standard string.c php3_string.h
References: 1 2 3 4  Groups: php.version4 
Request: Send a blank email to php-version4+get-4115@lists.php.net to get a copy of this message
Hi, 05.09.1999 v 13:45:10 (+0200), Sascha Schumann napsal: > > 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. really sorry for that. i was in a weird mood... > > > 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. it is. but there's no way how to escape in C-like style... let's finish it, that I'll revert the old php_stripslashes completelly (with that realloc) and the c-like escaping will be enabled when additional parameter is passed to addslashes(), since it won't be used for SQL escaping... I'll make the addslashes(...,...) even not honour magic_quotes_sybase. what to do with a fact, that stripslashes won't be a counterpart of addslashes() anymore? Jakub -- Jakub "RiffRaff" Skopal mailto:j@kubs.cz

« previous php.version4 (#4115) next »