Hi. Sorry about the delay. Had a blonde moment.
I've used a small script to process the CVS. There are 420 changes!!!
I've used the following regexps for a search/replace ...
$s_search =
'`add_assoc_(bool|double|long|null|resource|rt_stringl|rt_string|stringl|string|unicodel|unicode|zval)*\(([^,]*),
"(.*?)",`i';
$s_replace = 'add_assoc_$1_ex($2, "$3", sizeof("$3")+1,';
Everything SEEMS to look ok. Until I've got MS VC Express Edition
compiling ok, this patch is UNTESTED!! (Sorry about that).
Files changed.
php-src/ext/bz2/bz2.c
php-src/ext/calendar/calendar.c
php-src/ext/curl/multi.c
php-src/ext/curl/streams.c
php-src/ext/date/php_date.c
php-src/ext/dbase/dbase.c
php-src/ext/exif/exif.c
php-src/ext/fbsql/php_fbsql.c
php-src/ext/fdf/fdf.c
php-src/ext/gd/gd.c
php-src/ext/gmp/gmp.c
php-src/ext/hwapi/hwapi.cpp
php-src/ext/iconv/iconv.c
php-src/ext/interbase/ibase_blobs.c
php-src/ext/interbase/ibase_query.c
php-src/ext/interbase/ibase_service.c
php-src/ext/ldap/ldap.c
php-src/ext/mbstring/mbstring.c
php-src/ext/oci8/oci8_interface.c
php-src/ext/openssl/openssl.c
php-src/ext/pdo/pdo_stmt.c
php-src/ext/pdo_mysql/mysql_statement.c
php-src/ext/pdo_pgsql/pgsql_statement.c
php-src/ext/pdo_sqlite/sqlite_statement.c
php-src/ext/pgsql/pgsql.c
php-src/ext/posix/posix.c
php-src/ext/session/session.c
php-src/ext/soap/php_http.c
php-src/ext/sockets/sockets.c
php-src/ext/standard/basic_functions.c
php-src/ext/standard/datetime.c
php-src/ext/standard/dns.c
php-src/ext/standard/file.c
php-src/ext/standard/html.c
php-src/ext/standard/image.c
php-src/ext/standard/microtime.c
php-src/ext/standard/proc_open.c
php-src/ext/standard/streamsfuncs.c
php-src/ext/standard/string.c
php-src/ext/standard/url.c
php-src/ext/sysvmsg/sysvmsg.c
php-src/main/output.c
php-src/main/streams/filter.c
php-src/main/streams/memory.c
php-src/main/streams/xp_socket.c
Patch is available at
http://rquadling.phpnet.us/add_assoc_xxx__to__add_assoc_xxx_ex__diff.txt
Regards,
Richard Quadling.
On 22/07/06, Matt W <[EMAIL PROTECTED]> wrote:
> Hi Andrei,
>
> I see you applied my patch. However, the 5.2 code still isn't binary-key
> safe (you only changed the second occurrence of add_assoc_zval to the _ex
> version). Or was that intentional and you only want to change the behavior
> in 6?
>
> And you know 5.2's description is still wrong -- with "keys" at the end
> instead of "values"? :-) When you changed that part in HEAD last week, you
> also added a "the" -- "... as _the_ corresponding _values_" -- which was in
> my patch, if you want both branches *exactly* the same. :-P
>
>
> Matt
>
> P.S. The other patch you're talking about below... I think Richard Quadling
> said he'll do it.
>
>
> ----- Original Message -----
> From: "Andrei Zmievski"
> Sent: Friday, July 21, 2006
>
>
> > Yeah, that's probably a good idea. You can submit a patch if you
> > want. :)
> >
> > -Andrei
> >
> >
> > On Jul 21, 2006, at 6:04 AM, Matt W wrote:
> >
> > > Hi Richard,
> > >
> > > I think I've seen those instances that you're referring to. By
> > > fixed length
> > > string I assume you mean hard-coded "string_key". Yeah, I would
> > > think those
> > > should use add_assoc_*_ex() since the length is known (sizeof
> > > ("string_key")
> > > etc.) to save unnecessary strlen() calls.
> > >
> > > Unless compilers optimize the strlen("string_key") + 1 to a
> > > constant from
> > > the add_assoc_*() macro. But I wouldn't think that's the case...? :-/
> > >
> > >
> > > Matt
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
