On 04.09.2008 23:08, Stan Vassilev | FM wrote:
There won't be any bug reports, if the ini parser detects improper backslash
usage (i.e., using a backslash with a following character which doesn't form
correct escape combination) and stops with informative and descriptive
message explaining the
hi,
On Fri, Sep 5, 2008 at 9:00 AM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 04.09.2008 23:08, Stan Vassilev | FM wrote:
There won't be any bug reports, if the ini parser detects improper
backslash usage (i.e., using a backslash with a following character which
doesn't form correct escape
On 04.09.2008 23:08, Stan Vassilev | FM wrote:
There won't be any bug reports, if the ini parser detects improper
backslash usage (i.e., using a backslash with a following character which
doesn't form correct escape combination) and stops with informative and
descriptive message explaining the
On 05.09.2008 14:57, Stan Vassilev | FM wrote:
I read it. \D in the same string isn't a legal escaped combination and this
is where the user will be warned.
Nope. This is perfectly legal, too.
# php -r 'var_dump(\W\H\A\T?);'
string(9) \W\H\A\T?
--
Wbr,
Antony Dovgal
--
PHP Internals -
On 05.09.2008 14:57, Stan Vassilev | FM wrote:
I read it. \D in the same string isn't a legal escaped combination and
this is where the user will be warned.
Nope. This is perfectly legal, too.
# php -r 'var_dump(\W\H\A\T?);'
string(9) \W\H\A\T?
Hi,
If you'll treat the INI parsing exactly
Hi!
My proposal is to have a proper subset of the PHP string literal
parsing, with the additional feature of warning when a user has
What for? Who would EVER need to have tab or newline in the path? Who
this feature - recognizing \n and \r and \t in paths - would serve, what
use case do
Hi!
Furthermore, since when is INI compatibility a feature of PHP. I've
Since forever?
never considered I can simply upgrade my PHP and paste the old INI and
run like that with no tests whatsoever.
That's natural expectation. Unnatural is to have to reconfigure your
system with each
Stanislav Malyshev wrote:
Hi!
Furthermore, since when is INI compatibility a feature of PHP. I've
Since forever?
never considered I can simply upgrade my PHP and paste the old INI and
run like that with no tests whatsoever.
That's natural expectation. Unnatural is to have to reconfigure
Hi,
now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:
With =5.2 we allow
include_path = c:\foo\bar\
and treat the backslash as regular
hi,
On Thu, Sep 4, 2008 at 7:07 PM, Johannes Schlüter [EMAIL PROTECTED] wrote:
Hi,
now that we have a publicly available alpha on Windows we get the first
feedback from Windows users. Within quite short time we got two bug
reports (#45992 #45994) about a change in the ini-parsing:
With
On 04.09.2008 21:07, Johannes Schlüter wrote:
This was caused by the changes in the ini parser which are important,
but in my opinion this is a break where we should try to find a way to
keep the behavior, especially as it was in the recommended php.ini
file and other places before.
I have to
hi,
On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
but now it's too late for such changes,
we have to put the old behavior back.
Even if it may mean drop the new ini parser and features?
I'm waiting Jani's anwer on that.
Cheers,
--
Pierre
http://blog.thepimp.net |
Hi!
Even if it may mean drop the new ini parser and features?
Which features require \ to be special character? Maybe we could change
them so they do not?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
Pierre Joye:
hi,
On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
but now it's too late for such changes,
we have to put the old behavior back.
Even if it may mean drop the new ini parser and features?
If you can allow both old and new behavior to co-exist, then
I have to agree, this kind of change would be very frustrating for Win32
users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used to
write path like that and they'll continue to do it, so we'll have much
more bug reports after the
Stan Vassilev | FM wrote:
I have to agree, this kind of change would be very frustrating for
Win32 users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used
to write path like that and they'll continue to do it, so we'll have
much
Stan Vassilev | FM kirjoitti:
I have to agree, this kind of change would be very frustrating for
Win32 users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used
to write path like that and they'll continue to do it, so we'll have
Pierre Joye kirjoitti:
hi,
On Thu, Sep 4, 2008 at 7:27 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
but now it's too late for such changes,
we have to put the old behavior back.
Even if it may mean drop the new ini parser and features?
I'm waiting Jani's anwer on that.
allow using ini
18 matches
Mail list logo
