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
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
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
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
>>
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.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.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.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
2011.09.06 23:20 Ulf Wendel rašė:
> Am 06.09.2011 21:33, schrieb Stas Malyshev:
>> Hi!
>>
>>> Any new PHP major release is about setting new directions. I, Andrey
>>> and
>>> Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd
>>> after
>>> an "incubation" of some four years (5.3x se
2011.09.04 12:13 Reindl Harald rašė:
>
>
> Am 04.09.2011 06:37, schrieb Stas Malyshev:
>> Hi!
>>
>> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
>>> Forget the failed tests. A new PHP release is about improving the
>>> ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
>>> mysqlnd
2011.09.03 12:06 Lester Caine rašė:
> New thread ...
>
>>> My SUSE installs all have mysqlnd included in the core, As do other
>>> Linux distributions. I think for much the same reason that the windows
>>> builds do as well? The PHP development team have decided that
>>> -without-mysqlnd is require
2011.07.22 18:56 John Carter rašė:
> Hi,
>
> Are there any plans to make APC work in a similar way to Zend Guard et
> al so that we could distribute cache/dump files instead of the php
> source. Is this something that would be easy to add?
>
> Brian is this what you're working on? ("on disk cache"
2011.06.22 14:14 Reindl Harald rašė:
> Am 22.06.2011 07:24, schrieb Tomas Kuliavas:
>> 2011.06.21 23:27 Reindl Harald rašė:
>>> i do not understand any word and miss a simple str_is_utf8()
>>
>> Such function uses six lines in PHP.
>
> so why do you not post t
2011.06.21 23:27 Reindl Harald rašė:
> i do not understand any word and miss a simple str_is_utf8()
Such function uses six lines in PHP. You can write your own. I need locale
insensitive casecmp, typecasting to unsigned 32bit int and bunch of other
functions in PHP. Do I have wait for PHP implemen
2011.06.21 20:51 Reindl Harald rašė:
>> utf-8 is strict format. If you expect utf-8 and someone submits
>> something
>> else, you can tell that without any string function. You can verify
>> utf-8
>> strings in pcre. You can convert nbspace to regular space, if you want.
>> utf-8 does not have any
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
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.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.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.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.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
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
>
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#
> 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.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
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.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
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
>>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
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
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
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.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.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.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.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
2008 Gruodis 28, 11:41, Sek Kenan R Sulayman rašė:
> Hey Folks!
>
> I've been working with Zend Studio.
> Since I've uninstalled the suite, PHP is exiting with:
> Cannot find module (IP-MIB): At line 0 in (none)
> Cannot find module (IF-MIB): At line 0 in (none)
> Cannot find module (TCP-MIB): At l
> Hello all,
>
> Last week I submitted a bug report on the issue described below. The
> response (also below) was that this is not a bug. I fail to see how it
> could *not* be a bug given that strtotime is parsing an invalid date
> into a seemingly-arbitrary and definitely-meaningless number, rat
>> PHP4, PHP5 and PHP6 unicode_semantics = off work same way.
>
> No, they do not work in the same way.
> I.e. we were trying to make PHP5 work in the same way PHP4 did as much as
> we could, but that's not always possible.
In my case they do.
--
Tomas
--
PHP Internals - PHP Runtime Developme
> Lester Caine schrieb:
>> That sounds like just the sort of edge case that Derick is suggesting
>> needs logging for fixing up. unicode_semantics=on is just another bodge
>> to to make it happen rather than a solution. I think I understand your
>> description, and to my eyes it looks like a unicod
>> > We've discussed this a few times in the past and it's time to make a
>> > final decision about its removal.
>> >
>> > I think most people have agreed that this is the way forward but no
>> > one has produced a patch. I have a student working on unicode
>> > conversion for the Google Summer of
> We've discussed this a few times in the past and it's time to make a
> final decision about its removal.
>
> I think most people have agreed that this is the way forward but no
> one has produced a patch. I have a student working on unicode
> conversion for the Google Summer of Code and this woul
>> As for validity, since locale mechanism has a bunch of fallbacks, I
>> understand the validity concept is a bit blurred. I.e. you can have
>> regexp
>> to check all the -'s or _'s are in place but beyond that it's kind of
>> hard
>> to know what the question "is en_RU locale valid?" means.
>
>
> 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
>> 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
> 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
> 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
>> 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
>> 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
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
>> 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
> 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
>> 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
>> > > 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 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
> 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
> 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
>> > 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.
>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
>>> 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
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'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
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
> 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,
>>
>> 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
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
>>> 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
>> 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
> 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
>> 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
> 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
>> 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
>> 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
>> > 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_microsuck($data);
> }
>
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
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
> 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
>
>> --- 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
>>> 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
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
> 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
> 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
>> 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
>> 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
> 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
>> 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
> 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
> 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
>>>
>>> - 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
>> 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
>>> >
>>> > 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]:
>> 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
>> 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
>>> 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
>> >
>> > 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
>
> 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
>> 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
>> 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
> 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
1 - 100 of 114 matches
Mail list logo
