> Hello!
>
> I am trying to understand how PHP6 handling of unicode works, I think I am
> missing something.
>
> My config is:
>
>
> ; Unicode settings ;
>
>
> unicode.semantics = on
> unicode.runtime_encoding = iso-8859-1
> unicode.script_encoding = iso-88
>> And, if they don't, unfortunately, it will be one more reason not to
>> switch to PHP 6 :)
>
> I hate to be the one to burst our bubble, but unicode is a killer
> feature and PHP 6 will be adopted en masse, so if this isn't changed, it
> will simply mean the death of userspace stream wrappers fo
Hi,
Could you make unicode.semantics configurable at PHP_INI_ALL level? Or
maybe PHP6 has string functions that are not unicode aware?
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>> Hi,
>>
>> Could you make unicode.semantics configurable at PHP_INI_ALL level?
>
> No.
>
>> Or maybe PHP6 has string functions that are not unicode aware?
>
> All string functions are supposed to be able to work with both Unicode and
> binary strings.
> Unicode is just an addition, it doesn't mea
>> SquirrelMail scripts are designed to work with binary strings. They will
>> have to deal with emails written in many different character sets. In
>> some
>> cases scripts must know string length in bytes and not in symbols. If
>> PHP
>> starts converting email body or message parts, strings won'
>> strlen("\xC4\x85") = 2. strlen((binary)"\xC4\x85") = 4. Not good. It is
>> one character in utf-8.
>
> I'm afraid I don't understand you again..
0xC4 and 0x85 are hex codes for latin small letter a with ogonek in utf-8. ą
If script is written in utf-8, I expect bool(true) on var_dump() line.
> Disclaimer: I don't know much about the way unicode is implemented in
> php, i have only used it a bit, but i believe i can clear some things
> up here.
>
>> 0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
>> utf-8. ą
>>
>> > var_dump("ą" == "\xC4\x85");
>> echo "ą\n";
>> echo
>> Latin capital letter A with diaeresis is 00C4. Not C4.
>
> Pay attention in maths, leading zeroes don't change a number.
they do, if it is not a number.
'00C4' + '0085' = '00C40085'
'C4' + '85' = 'C485'
'00C40085' != 'C485'
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing Lis
>> 0xC4 and 0x85 are hex codes for latin small letter a with ogonek in
>> utf-8. ą
>>
>> > var_dump("ą" == "\xC4\x85");
>> echo "ą\n";
>> echo "\xC4\x85";
>> ?>
>>
>> If script is written in utf-8, I expect bool(true) on var_dump() line.
>
> var_dump("ą" == b"\xC4\x85");
>
> This will give you what
>
> 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.
I can't maintain two different library versions, because i
>> >
>> > 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]:~$ php -r 'ech
>>> works fine here... (with php 5.2)
>>
>> http://www.php.net/ChangeLog-5.php#5.2.1
>>
>> - Added forward support for 'b' prefix in front of string literals.
>> (Andrei)
>>
>>
>> PHP 5.2.0
>> Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in
>> test.php on line 5
>>
>> PHP 4.1.2
>> No problem. I just can't use it. It does not pass even basic "must
>> work on
>> Debian Stable" test. Option creates parsing errors in older PHP
>> versions
>> and I can't wrap it with PHP6 check. Such code must be stored in
>> separate
>> libraries loaded only in PHP6 and issue affects way to m
>> 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
>>> >
>>> > 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]:
>> During Derick's talk about PHP 6 at PHP Vikinger, I started to wonder
>> what exactly was the reasoning behind adding something like
>> "unicode.semantics" option. Derick didn't remember, neither did I.
>>
>> Apparently it's another one of these "register_globals" or
>> "magic_quotes_*" directiv
>>> - This feature doesn't bring BC - there will still be enough BC
>>> breaks.
>>
>> Name one, please. The idea is that there shouldn't be any, so if you
>> have found one, please file a bug.
>
> Some might say removing register_globals, magic_quotes_*, etc. are BC
> break.
If code is portable
> Pierre wrote:
>> On 6/19/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>>
>>> But this is no different from writing code that will work on both PHP 5
>>> and PHP 6. The only difference is that instead of checking for PHP 5
>>> you will be checking for Unicode. Like I said, we don't want the
>>>
> On 19/06/07, Tomas Kuliavas <[EMAIL PROTECTED]> wrote:
>> I don't care about Unicode support, because it breaks things. I suspect
>> that PHP6 Unicode extension won't give me controls that I have in PHP5
>> and
>> PHP4 strings. PHP6 Unicod
>> We are working on different code. You have code with some specific
>> character set and you can control all strings.
>
> Tomas, stop arguing on this. As a library maintainer, I agree with you and
> I don't understand where the
> 'killer feature' is (I heard that Yahoo China asked for it, or is i
> No one is going to write code in their own native language and
> distribute it worldwide.
>
> How can you say that "PHP6 Unicode support is not designed for
> international environment"? Have you even tried it?
Ok. International environment.
Do you have strtoupper|strtolower|strcasecmp function
>> It comes down to predicting the future. Whichever way we go, the
>> decision is going to be second-guessed. If we have critical mass for
>> a
>> clean BC break, then I am ok with it. For me personally it would make
>> things a bit easier, but I think it would be a long long time before
>> we
>> Unicode code points can be defined with \u, but PHP6 breaks existing
>> octal
>> and hex escape sequences.
>
> What do you mean? Doesn't \x20 create U0020 character? Or you mean you'd
> expect it to create just one-byte 0x20? Doesn't binary string do that?
Try higher than 0x7F values.
If I wri
> Call to developers:
> Create new versions of your apps/libraries which use new features of
> language. Make your users interested in upgrading. If users want it,
> hosting-owners will consider upgrades faster. It's all about
> marketing ;)
It also depends on your marketing policy. PHP 5.2.1 req
> It sounds like your libraries are definitely oriented towards working
> with binary strings, rather than Unicode strings. So, I am not sure
> why you have unicode.semantics turned on then. If you turn it off,
> you will get backwards compatibility with PHP 5. And if you do that,
> you can still c
Hi,
I've tried to profile scripts with Zend Profiler (Zend Studio 5.5 Linux
trial on local host + Zend Platform 3.0.2 Linux trial on remote vmware
host) and noticed that script with include() call has higher load time. I
have't found explanation of performance differences between include and
inclu
>>> Unicode code points can be defined with \u, but PHP6 breaks existing
>>> octal and hex escape sequences.
>
> I don't understand what this means...
PHP6.0-200707060630
unicode.fallback_encoding => 'utf-8' => 'utf-8'
unicode.filesystem_encoding => no value => no value
unicode.http_input_encodin
>> --- test.php ---
>> > $string1 = "ą";
>> $string2 = "\xC4\x85";
>> var_dump($string1 == $string2)
>
> How you expect one-character string to be equal to two-character string?
In PHP4/5 \xC4 and \x85 are not characters. They are bytes.
>> ą is in utf-8 (latin small letter a with ogonek, latin e
> I have my arguments. One of them is because you keep mantaining PHP4
> for a long time.
> If you had "found a very dangerous issue in PHP4 that could not be
> resolved without moving to PHP5", I think the adoption would be
> greater. Information is everything and manipulating people's fears is
>
Looks close to
http://www.nexen.net/chiffres_cles/phpversion/16987-php_stats_evolution_for_april_2007.php
> Hello Vesselin,
>
> what is the source of your numbers?
>
> Best Regards,
>
> Oliver
>
>
> Vesselin Kenashkov schrieb:
>> -1
>> Because the majority of the installation (somebody two month
Well, then I guess we have no choice but to declare official PHP 4
end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable
timezone :)
>>
>> Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
>> it otherwise will be 20:08:08 when we spe
Unicode code points can be defined with \u, but PHP6 breaks
existing octal and hex escape sequences.
>>
>> I don't understand what this means...
>
> I think I know...
>
> I have code like this, somewhere:
>
> if (preg_match("|[\xF0-\xFF]|", $data)){
> $data = un_microsuck($data);
> }
>
>> > I think the sooner the better as it's valuable information for the dev
>> > team.
>> > It'd probably be a good idea to have a Wiki where we can document
>> issues
>> > that/common use-cases which are encountered.
>> > Maybe we should have a Wiki on one of the php.net servers for such
>> > purp
>> Unicode code points can be defined with \u, but PHP6 breaks
>> existing octal and hex escape sequences.
I don't understand what this means...
>>>
>>> I think I know...
>>>
>>> I have code like this, somewhere:
>>>
>>> if (preg_match("|[\xF0-\xFF]|", $data)){
>>> $data = un_m
>> But if you write:
>>
>> $a = "マニュアル";
>> echo $a[1];
>
> Whoa.
>
> That was weird...
>
> It was just a bunch of question marks when I read it, and now it's a
> bunch of symbols (variants on afz mostly) in my reply...
Your browser or operating system does not support Japanese symbols and
transla
> That sounds "good" in my ears.
>
> Software that relys on "old" non-unicode behaviour must be written in a
> way two handle non-unicode and Unicode behaviour in two different ways.
> But for example a rewritten "Squirrelmail" that runs exlusively on PHP6
> would be a good thing.
>
> So you could
>> 50% increase sounds off base. But I did not bench php6 yet. When all
>> the new features are implemented, it will make more sense to work on
>> the performance problem. For now, it is simply premature.
>
> If Moore's law stands for the coming years, this argument is moot anyway.
> By the time PH
> From the low end user perspective I think this would be great from
> another POV. Let's imagine for a second that Wordpress will only work
> with unicode semantics off and that phpBB will only work with the switch
> "on". What if someone would want to run both on a shared server?
from httpd.c
>> Someone in the Doctrine channel just brought up the issue of having to
>> look forward to ensure mid term compatibility when choosing names for
>> identifiers. I guess with namespaces and other things will add new
>> reserved words. I think we should have a prominent place on php.net with
>> ear
>>> FINALLY we're getting somewhere. Now where to start removing all the
>>
>> I don't see how we are getting somewhere - as before, there are people
>> for removing it and against removing it. Nothing changed, as far as I
>> see. Why suddenly should we start removing anything?
>
> For some reason
Hi,
If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe you
need other bug report?
--
Tomas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>> Hi,
>>
>> If bug is tagged as 'No feedback' (18556) or 'Won't fix' (35050) and can
>> be reproduced in current PHP5 and PHP6, is it closed or open? Or maybe
>> you
>> need other bug report?
>
> Wont fix means wont fix..and in this case 'no feedback' means also 'wont
> fix'
> since it's the same
> So what happened to the "Open" in "OpenSource" or is PHP now something
> else now?
>
> btw. 95% of Zend users propably don't need unicode but there are a lot
> more people out there who can't really use PHP right now since it
> doesn't have full unicode support. The percents pulled out of sleeve
Hi,
Maybe somebody could provide good explanation why you can fix the issue
(http://bugs.php.net/bug.php?id=42526). You can't claim that locale
insensitive tolower() breaks things, because your functions are locale
insensitive in some setups.
Now I can only see that PHP developers close bug repor
I'll add comments on 35050 and you will ignore it, because bug is not open.
You have patch on http://bugs.php.net/bug.php?id=35583. I understand why
it might have been rejected. Using mapping table to lowercase ascii is not
optimal solution.
I have other patch, but you are not free to use code li
ns, please add comment to the report marked as "Wont
> fix" and don't spam the already huge database with one more report about
> same issue.
>
> --Jani
>
>
> On Mon, 2007-09-03 at 14:16 +0300, Tomas Kuliavas wrote:
>> Hi,
>>
>> Maybe somebo
>>> I need some assistance gathering the information that might be most
>>> helpful.
>>>
>>> This week sometime I will grab a snapshot and install it. Normally I
>>> install php via the FreeBSD ports collection. I am happy to build a
>>> custom version but I would like to make sure that I do not
>when developing a patch like this, it is more readable to do typical
> min max notation to ease readability. That is change:
> if (91 > i && i > 64) {
> To:
> if (64 < i && i < 91) {
>
> the real issue here is that if we fix it this way we break other locales.
How they break? Do you want to s
>> > Yes, remove any lines in your php.ini that reference those files.
>
> Thanks for your response...
>
> i have commented the mysql.so module in php.ini.. but i couldn't find
> another two modules in php.ini...
>
> which files are related to odbc.so and pdo_odbc.so modules??
Test your PHP setup.
> A preliminary implementation of PHP taint support is available from
> ftp://ftp.porcupine.org/pub/php/ This code is released under version
> 2.00 of the Zend license.
>
> Below are fragments from the README file. For the full text please see
> ftp://ftp.porcupine.org/pub/php/php-5.2.3-taint-20071
> Tomas Kuliavas:
>> > A preliminary implementation of PHP taint support is available from
>> > ftp://ftp.porcupine.org/pub/php/ This code is released under version
>> > 2.00 of the Zend license.
>> >
>> > Below are fragments from the RE
> On Fri, 23 Nov 2007, Rasmus Lerdorf wrote:
>
>> Marcus Boerger wrote:
>> > Hello internals,
>> >
>> > can we please officially announce the end of support for PHP 4*,
>> 5.0.*,
>> > 5.1.* as 31st december 2007? Officially as in on the front of php.net.
>>
>> We already set the EOL date for PHP
>> > > However, a ~couple months ago IBM gave permission to remove this
>> > > copyright (because the authors are listed as general contributors,
>> > > thus representing IBM) although we've not yet implemented this
>> > > removal. We did [temporary] remove it about six months ago but...
>
> There
>> On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
>>> 3) 2+ bigger codebase [1] (with lots of duplicates because we have to
>>> do
>>> same things in native and unicode modes);
>>
>> From the cross-reference I assume you mean PHP's codebase. We still
>> need binary string support — Unicode is only
> 3) 2+ bigger codebase [1] (with lots of duplicates because we have to
> do
> same things in native and unicode modes);
>
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for textual
content. Im
>> 5) this is yet another reincarnation of ze1_compatibility switch.
> Which is the worst mistake ever imo - If you wanted PHP 4 you would simply
> use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for on
5) this is yet another reincarnation of ze1_compatibility switch.
>>> Which is the worst mistake ever imo - If you wanted PHP 4 you would
>>> simply
>>> use PHP 4. Now if you want PHP 5 just damn use PHP 5.
>
>> And if you don't control PHP version used by end user? Only bad in-house
>> apps a
>> Should really theses functions discard the whole string for a single
>> incomplete sequence ?
>
> I think since it is not possible to recover true content of the string,
> it is ok to return failure value. Cutting it in random places or
> ignoring problems doesn't seem a good idea - it might lea
>> Instead of using simple sanitizing function users are forced to check
>> for errors. How good is that? It makes code complex or unreliable.
>
> Explain me again how checking for errors makes code unreliable?
OR unreliable. If you check for errors, sanitizing code is complex. If you
don't check
> That part is completely different. That's at the display level.
> Replacing it in the backend makes no sense to me. Don't use
> utf8_decode. Use iconv() so you know what the heck is going on.
:)
iconv() will stop on conversion error and return partial string or empty
string. It will require
> On Thursday 07 February 2008, Lukas Kahwe Smith wrote:
>> On 07.02.2008, at 00:59, Pierre Joye wrote:
>> > Hi Andi,
>> >
>> > On Feb 7, 2008 12:56 AM, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>> >> -1
>> >>
>> >> Suggestion to enhance the suggestion: return false + emit E_STRICT
>> >> message (but
>> So I guess I'm -1: Restore them, always return false, and throw
>> E_DEPRECATED.
>
> But this was about them being in PHP 6, not PHP 5..
> If magic_quotes_* is gone, so should anything else even remotely related
> to them be gone. You have to fix your code anyway for it to work in PHP
> 6 (or ev
> If those application are written properly, they also have to check for
> the existance of the functions even with current PHP version since it is
> possible to disable them altogether. So it shouldn't matter if they're
> removed for them.. ;)
Function is standard for PHP4-5. get_magic_quotes_gpc
On 2021-01-07 11:00, Claude Pache wrote:
Le 6 janv. 2021 à 16:46, Nikita Popov a écrit :
On Sat, Dec 26, 2020 at 12:03 PM Craig Francis
wrote:
Hi,
Could htmlspecialchars() use ENT_QUOTES by default?
I recently worked on an example script, where I tried to keep it simple by
using htmlspec
ker.
> Do you consider this a bug? How are you relying on these overflown
> numbers?
>
> Andi
>
>
> At 12:50 PM 10/4/2004 +0200, M. Sokolewicz wrote:
>
>> You might want to ask this on the internals list (cc'd)
>>
>>
>> Tomas Kuliavas wrote:
>
2012.02.02 19:42 Reindl Harald rašė:
> security is THE benefit for ALL users, especially in days where many
> are running crap-code like Joomla/Wordpress with all sorts of plugins
> throwing millions of warning if you run with E_ALL and E_STRCIT
E_STRICT throws notices on properly written code. It
2012.03.06 23:03 Michael Morris rašė:
> https://wiki.php.net/rfc/php_ini_bcmath_default
>
> This is the only other RFC I've been rummaging around in my head but
> hadn't brought up.
PHP has something similar with mbstring function overloading. If people
use both string and mbstring functions, they
2012.03.13 16:38 Richard Lynch rašė:
> I'd have to agree with Stas that everybody should start passing in a
> variable there, that can be set somewhere in a config, or, perhaps,
> would DEFAULT to, e...
You do realize that suggestions on this thread and original bug reporter
failed to make cor
2012.07.11 19:17, Stas Malyshev rašė:
> Hi!
>
>> I don't think ASCII-only lowercasing is compatible to the allowed PHP
>> identifier characters used by class names and what else.
>
> Right now we use tolower() which is system-dependent, locale-dependent
> and doesn't really work with any characte
2012.07.11 23:07, Pierre Joye rašė:
> hi,
>
> On Wed, Jul 11, 2012 at 10:01 PM, Stas Malyshev
> wrote:
>> Hi!
>>
>>> I'd to go with master only with this patch, not like it is a huge
>>> issue either (% wised I mean).
>>
>> It's a huge issue for people using these locales (PHP is unusable for
>>
2019.09.15 06:32 Mike Schinkel rašė:
> https://medium.com/@trungluongquang/why-python-is-popular-despite-being-super-slow-83a8320412a9
> 1. End-users just don’t care (about slower performance)
Which means that your code is running data processing and not interactive
user facing frontend. Put 10 se
2020.03.08 16:08 Dan Ackroyd rašė:
> On Tue, 3 Mar 2020 at 22:17, Christoph M. Becker
> wrote:
>>
>> for more
>> general string functionality, it would be ext/mbstring.
>>
>> Thoughts?
>>
>
> Related to this discussion, please could someone remind me why the
> mbstring extension is an extension an
> The 2nd release candidate for PHP 5.2.1 is now available for download.
> The tarballs can be found here:
>
> http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2
> (d3889eda8c3471ce7cf2adb35a4de736)
> http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz
> (c5b3e5540d1951d4c4b976b8a39c09ab)
>
> and t
>>> The 2nd release candidate for PHP 5.2.1 is now available for download.
>>> The tarballs can be found here:
>>>
>>> http://downloads.php.net/ilia/php-5.2.1RC3.tar.bz2
>>> (d3889eda8c3471ce7cf2adb35a4de736)
>>> http://downloads.php.net/ilia/php-5.2.1RC3.tar.gz
>>> (c5b3e5540d1951d4c4b976b8a39c09a
Is it that difficult to replace strcasecmp with locale independent
case insensitive comparison function?
>>>
>>> We're open for patches. Feel free to send one.
>>
>> I am PHP developer and don't code in C. In PHP script locale insensitive
>> strtolower/strtoupper can be done with one preg
> Hi there,
> looking around quickly I couldn't find any documentation on the
> following change:
> $a = "foo"; echo "\{$a}";
>
> PHP 4.4.4: {foo}
> PHP 5.2.1: \{foo}
>
> I didn't check which exact version introduced this change. Some
> third-party code used this obscure construct and failed when m
>> Surely we must to keep a setting just because two people in the world
>> use it.
>> I'm afraid their apps won't run on PHP6 anyway because of numerous major
>> changes
>> (already done and still planned), so one more cleanup won't hurt anyone.
>
> This isn't cleanup. This is dropping a feature w
> Hi Tomas,
>
> - Original Message -
> From: "Tomas Kuliavas"
> Sent: Friday, April 13, 2007
>
>> ASP tags do collide with some html markup.
>>
>> Boom.
>
> That's not a problem. :-) If you're in PHP, that would be a string;
> The last time I used ASP tags: Never.
>
> I wish they'd just go forever! People keep trying to use the on my
> servers, fail and ask me to turn PHP's asp_tags on, I refuse, because I
> run a shared PHP install, and so they move off elsewhere, rather than
> change their code.
asp_tags can be set
2009.09.09 19:12 Tony Marston rašė:
> I have reported this problem in http://bugs.php.net/bug.php?id=49238. It
> would appear that this option, which was first made available in PHP
> 4.2.0,
> has been silently dropped. Apparently the decision was made in order to
> fix
> http://bugs.php.net/bug.ph
2009.09.10 11:17 Tony Marston rašė:
>
> ""Tomas Kuliavas"" wrote in message
> news:40100.4e3f9432.1252518200@avilys.eik.lt...
>> 2009.09.09 19:12 Tony Marston rase:
>>> I have reported this problem in http://bugs.php.net/bug.php?id=49238.
>>
2009.09.10 15:25 Tony Marston rašė:
> There is no set_up_language() function, and what has SquirrelMail got to
> do with PHP?
>
> Unless you can point to some official documentation on the PHP web site
> your "advice" is totally unsubstantiated and virtually worthless.
This "advice" is the only ad
2009.10.12 19:22 Mark Krenz rašė:
>
> Just to clarify. You mean that with the changes you've made for
> Unicode support in PHP 6, that current POSIX based ereg expressions will
> not work the same?
Expressions didn't work 1,5 year ago.
http://bugs.php.net/bug.php?id=44923
Maybe current PHP6-de
2009.10.12 20:55 Carl P. Corliss rašė:
> Lukas Kahwe Smith wrote:
> [snip]
>
>> On 12.10.2009, at 18:57, Mark Krenz wrote:
>>
>>> On Mon, Oct 12, 2009 at 04:27:02PM GMT, Pierre Joye
>>> [pierre@gmail.com] said the following:
> [snip]
>
>>> But I'm willing to bet that the majority of people are
2009.12.09 22:38 Chris Stockton rašė:
> Hello,
>
> I am trying to use ChoiceFormat in the Intl extension. When I try to
> do something like:
>
> $r = new MessageFormatter("en", "There are {0≤are no files|1≤is one
> file|1 // $r is NULL
>
> This may be a incorrect use, but my thought is that regardl
Keryx Web rašė:
2. If so, what will happen to array access in strings that are de facto
Unicode? Will the more clunky mb_substr() be the only option?
What will happen to array access in unicode strings, if code wants to
access them in bytes? Will some backwards incompatible binary be the
only
>>happen in its original form, I think we're going to need to revisit
>>how we want to deal with this. There's a patch linked in the bug from
>>Tomas Kuliavas and Marcus that fixes the problem by simply redefining
>>zend_tolower() to a simple locale-insensitive ASCII tol
2010.05.04 17:56 Derick Rethans rašė:
> On Tue, 4 May 2010, Adam Harvey wrote:
>
>> The options are:
>>
>> 1. Apply Tomas's patch to make case-insensitive lookups
>> locale-ignorant. Pros: fixes immediate problem. Cons: breaks BC for
>> case-insensitive function/method name lookups for high-bit cha
2010.05.04 20:20 Tomas Kuliavas rašė:
> 2010.05.04 17:56 Derick Rethans rašė:
>> On Tue, 4 May 2010, Adam Harvey wrote:
>>
>>> The options are:
>>>
>>> 1. Apply Tomas's patch to make case-insensitive lookups
>>> locale-ignorant. Pro
Such software could allow webmaster to reconfigure PHP without terminal
connection. Although some PHP configuration variables are not global and
can be changed without modifying global PHP settings. Zend sells software
which allows to change global PHP configuration in web browser (among
other feat
2010.06.05 21:18 Mike Willbanks rašė:
> Tomas,
>
> Such software could allow webmaster to reconfigure PHP without terminal
>> connection. Although some PHP configuration variables are not global and
>> can be changed without modifying global PHP settings. Zend sells
>> software
>> which allows to c
> That was my inital goal.
>
> I wanted to controll php by a webfronted.
>
> I currently have a problem with writing php vars into the ini file.
>
> Many thanks for your input concerning the security problem.
>
> Alexander
>
> On Sat, Jun 5, 2010 at 12:21 PM, Tomas Ku
2010.07.30 17:13 Pierre Joye rašė:
> What make you think that c-client is dead? I have seen updates last
> year and I know that the main developer still works and support this
> library.
IMHO main developer works on Panda IMAP. Source code is not publicly
available (http://panda.com/imap/FAQ.html#
2010.08.12 09:59 Lester Caine rašė:
> > Currently I am still working my way through the holes in PHP5.3.x which
> is why
> > PHP5.2 is STILL the last stable release as far as my ( windows )
> customer sites
> > are concerned. SO sensible debate on the next step forward IS more
> important and
>
2011.03.15 22:09 Olivier Hoareau rašė:
> Hi !
>
> I would like to be able to "distribute" (freely) a single executable
> (binary) containing :
>
> - php binaries (v 5.3+)
> - a php script already packaged as a .phar (1 Mb, requiring PHP 5.3+)
> - additional (optional) compiled extensions
> - php.in
2011.03.15 23:08 Olivier Hoareau rašė:
> Hi Tomas !
>
> Thanks for your proposals.
>
>
>> Create .deb package and make it dependent on PHP for Debian/Ubuntu.
>> Debian
>> has docs and tools that allow to do that. PHP is in standard
>> Debian/Ubuntu
>> software repository.
>>
>
> This solution does
2011.04.03 13:58 Tomas Brastavičius rašė:
> Hi,
>
> can somebody review the following patch:
> http://bugs.php.net/bug.php?id=54369
>
> I am willing the bug is fixed in the next PHP release and ready to do a
> job if something is wrong with the patch.
Check url encoding documentation first.
http:/
2011.06.20 21:38 Robert Eisele rašė:
> I really like the ideas shared here. It's a thing of consideration that
> array-functions should also work with strings. Maybe this would be the way
> to go, but I'm more excited about the OOP implementation of TextIterator
> and
> ByteIterator, which solves t
2011.06.21 17:38 John Crenshaw rašė:
> Pierre Joye wrote:
>> On Tue, Jun 21, 2011 at 1:33 PM, Lester Caine
>> wrote:
>>> Pierre Joye wrote:
>
> It depended on ICU there, and I would be against making a core thing
> in
>> PHP 5.x depend on ICU.
It can and should be done a
2011.06.21 19:24 Reindl Harald rašė:
>
>
> Am 21.06.2011 18:22, schrieb Ferenc Kovacs:
>> On Tue, Jun 21, 2011 at 6:14 PM, Reindl Harald
>> wrote:
>>
>>>
>>>
>>> Am 21.06.2011 17:55, schrieb Tomas Kuliavas:
>>>
>>>> Th
1 - 100 of 114 matches
Mail list logo
