Re: [PHP4BETA] cvs: /php4/ext/standard string.c php3_string.h
| From: | Jakub Skopal | 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