>>> >
>>> > Recent versions of PHP5, has a binary string introducer.
>>> >
>>> > echo strlen(b"\xC4\x85");
>>>
>>> I have already said to Stefan. It is not an option. I need backwards
>>> compatibility. If older PHP versions fail with E_PARSE errors, I
>>> can't use
>>> it.
>>
>> [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The windows build:
http://downloads.php.net/edink/php-5.2.3RC1-Win32.zip
http://downloads.php.net/edink/php-5.2.3RC1-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.3RC1-Win32.zip
http://downloads.php.net/edink/php-debug-pack-5.2.3RC1-Win3
The first release candidate of PHP 5.2.3 is now available for testing
and can be downloaded here:
http://downloads.php.net/ilia/php-5.2.3RC1.tar.bz2 (md5sum:
343785b0558f5696c14607d62f084d4c)
The release comes a bit sooner then anticipated as it is needed to
address a regression introduce
What prompted this? I'm not keen on changing the parser unless there is
some benefit. Speed, portability, fixing a reported issue, etc. The
one risk I see here is that isxdigit() is a LOCALE-aware function, so
first, it is likely slower than what it replaces here, and second, a
messed up LOCALE
I think the current code is better and not to mention faster. Shorter
code in this case does not mean better code.
On 24-May-07, at 7:50 PM, Martin Majlis wrote:
Just small refactoring. Replacing self-made function with functions
from standard headers.
Index: JSON_parser.c
=
Just small refactoring. Replacing self-made function with functions
from standard headers.
Index: JSON_parser.c
===
RCS file: /repository/php-src/ext/json/JSON_parser.c,v
retrieving revision 1.1.2.8
diff -u -u -r1.1.2.8 JSON_parser.c
Richard Lynch wrote:
Get the world to update to 5.2, and all is good...
That seems unlikely to happen in the immediate future, afaics, no
matter how much we might wish it did.
This is true.
RHEL 5 just came out in March with PHP 5.1.6. They appear to be on a 3
year release cycle. Just try
We at one time discussed some sort of default fallback encoding as far
as I recall, and if that isn't defined, the default fallback would be
the runtime encoding. I think it would ease migration headaches quite a
bit I think if we could make some informed guesses on some of these
functions that as
urlencode() requires binary because at the time we were discussing
it, we could not see what encoding to apply by default, since neither
runtime encoding nor output encoding quite fits. Perhaps we could do
something like another parameter that specifies the encoding to use,
but we won't be
On Tue, May 22, 2007 1:12 pm, Derick Rethans wrote:
> On Tue, 22 May 2007, Tomas Kuliavas wrote:
>
>> >
>> > Recent versions of PHP5, has a binary string introducer.
>> >
>> > echo strlen(b"\xC4\x85");
>>
>> I have already said to Stefan. It is not an option. I need backwards
>> compatibility. If
Many of the function name idiosyncracies stem from PHP being a "glue"
language to tie together disparate libraries.
The function names are the same as in the libraries, so one can read
the docs for the libraries (eg mysql) and not have to "guess" what the
function got renamed to in PHP -- it's the
> > What I am thinking is, if unicode_semantics=on, every single time I need
> > to call urlencode (or other binary-only functions) with a variable, I
> > need to typecast it. Well, if this is necessary 100% of the times, why
> > not do this already inside urlencode, and if the string contains bad
> I jst compare urlencode/urldecode with Java that is from its nature using
> Unicode.
>
> http://java.sun.com/javase/6/docs/api/java/net/URLEncoder.html
>
> The input parameter is a *String* (which is per definition Unicode in
> Java). The output is (a ASCII-only) string with the URL-encoded val
Rangel Reale wrote:
> I am testing my 25000 lines PHP5 application on PHP6, just to see what
> changes it would require. I changed exactly 5 (yes only 5) lines of
> code, and it worked perfectly except for the functions that requires
> binary string parameters with a (binary) typecast.
>
> What I
Unicode support is a rather major milestone for PHP. It is one of the
biggest changes to the codebase ever. I don't think anybody can
seriously argue that decent Unicode support isn't worth the effort and
it is somewhat unrealistic to think that this can be done while keeping
it perfectly backwa
Tomas Kuliavas wrote:
>>> Hoepfully this project will learn something with the previuos
>>> experiences ( PHP5 adoption anyone? ) and think in a reasoanble
>>> backward compatibility policy.
>> This is a different story: From what I'm reading Unicode support is for
>> many people way more interesti
>> Hoepfully this project will learn something with the previuos
>> experiences ( PHP5 adoption anyone? ) and think in a reasoanble
>> backward compatibility policy.
>
> This is a different story: From what I'm reading Unicode support is for
> many people way more interesting than many things intro
Hi Christian,
On Thu, 2007-05-24 at 05:19 -0400, Cristian Rodriguez wrote:
> 2007/5/22, Andrei Zmievski <[EMAIL PROTECTED]>:
> > Nobody is breaking your code.
>
> Yes, it does break code, unicode.semantics is ZEND_INI_SYSTEM, hence
> I cannot even turn it off with htaccess.
I think it was once
Hi Ilia,
Did you see the last message...? Any reason not to apply the patch I sent
to prevent future bug reports/simplify code?
http://news.php.net/php.internals/29315
Matt
- Original Message -
From: "Matt Wilmas"
Sent: Tuesday, May 08, 2007
> Hi Ilia, all,
>
> I've attached patches
Vesselin Kenashkov wrote:
Here is the first one - how one can find does a SimpleXMLElement has child
nodes?
Here is an example:
$str = '';
$x = new SimpleXMLElement($str);
if($x->subnode->children())
print 'yes';
else
print 'no';
-
will print 'no';
If the
$str='';
2007/5/22, Andrei Zmievski <[EMAIL PROTECTED]>:
Nobody is breaking your code.
Yes, it does break code, unicode.semantics is ZEND_INI_SYSTEM, hence
I cannot even turn it off with htaccess.
You are free to use unicode.semantics
or turn it off.
No, I cant. redistributable applications (most o
Hi all
This bug was never fixed in 4_4 (the original news entry said it was)..
Shouldn't it be merged to 4_4?
-Hannes
-- Forwarded message --
From: Antony Dovgal <[EMAIL PROTECTED]>
Date: May 22, 2007 4:34 PM
Subject: [PHP-CVS] cvs: php-src(PHP_5_2) /ext/standard
basic_functions
22 matches
Mail list logo
