Is the patch to use the _ex functions needed?
On 24/07/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
Fixed now.
-Andrei
On Jul 24, 2006, at 12:52 AM, Matt W wrote:
> Hi,
>
> - Original Message -
> From: "bertrand Gugger"
> Sent: Monday, July 24, 2006
>
>
>> Matt W wrote:
>>> Hi Andr
Fixed now.
-Andrei
On Jul 24, 2006, at 12:52 AM, Matt W wrote:
Hi,
- Original Message -
From: "bertrand Gugger"
Sent: Monday, July 24, 2006
Matt W wrote:
Hi Andrei,
I see you applied my patch.
Testing with a php5.2-200607222030 snaps having
/* $Id: array.c,v 1.308.2.21.2.7 2006
Matt W wrote:
Nope, it's broken. :-)
Thx to confirm the report ,
It's old linux here , so maybe it's related.
I did a full report of the whole run-tests with the snap from 06:30 this
morning and this minimal build.
(attached for complements of info)
off topic:
As recommended (7 other fail
Hi,
- Original Message -
From: "bertrand Gugger"
Sent: Monday, July 24, 2006
> Matt W wrote:
> > Hi Andrei,
> >
> > I see you applied my patch.
> Testing with a php5.2-200607222030 snaps having
> /* $Id: array.c,v 1.308.2.21.2.7 2006/07/22 16:58:39 andrei Exp $ */
>
> Looks by me as the
Either way, is it worth committing the patch ?
1 - For the non-optimizing compilers.
2 - Consistency across all source - static string use sizeof() rather
than strlen() +1
If so, I'll need to amend the patch to NOT use +1, though judging by
the comments made by bertrand Gugger, maybe something n
Matt W wrote:
Hi Andrei,
I see you applied my patch.
Testing with a php5.2-200607222030 snaps having
/* $Id: array.c,v 1.308.2.21.2.7 2006/07/22 16:58:39 andrei Exp $ */
Looks by me as the ext/standard/tests/array/array_combine.phpt fails
Is it by me ?
$ diff -W 60 -y --suppress-common-lines
Most compiler (I know gcc and Visual C do) will optimize strlen
("static_string").
On 21-Jul-06, at 9: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 thos
Hi Richard, Andrei,
Hold on about a patch to optimize add_assoc_* and hard-coded keys. I just
finished some testing to see what difference it makes: none! :-) Compilers
must optimize strlen("static string") to the literal value; at least VC++
Express does. Using a dynamic string from estrdup(),
Hi Richard,
Replacement script made it pretty simple I guess. :-) But sizeof("key")+1
should just be sizeof("key") (which == strlen("key")+1).
Are there any uses of add_u_assoc_* with hard-coded keys?
These changes make things look a little messy, you think? The string is in
2 places, etc...
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)*\(([
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 "k
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 t
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 compil
Hi,
There are 46 uses of add_assoc_zval() in the CVS. Many are with fixed
length strings for the key. Should the others all be using
add_assoc_zval_ex() ?
On 21/07/06, Matt W <[EMAIL PROTECTED]> wrote:
Hi,
I don't know if array_combine() was intentionally made binary-key unsafe,
but it seems
14 matches
Mail list logo
