On 31.08.2008, at 15:37, Lukas Kahwe Smith wrote:
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am
thankful that Marcus and Felipe ha
On Sat, Sep 6, 2008 at 1:19 AM, Rodrigo Campos <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I am writing to the list because there's a bug in the php snmp
> extension that leaks memory. This bug has been reported by Federico
> Cuello two months ago here: http://bugs.php.net/bug.php?id=45405
>
> As you can
Scott MacVicar wrote:
Stanislav Malyshev wrote:
Hi!
That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things
Stanislav Malyshev wrote:
> Hi!
>
>> That's exactly why I am reluctant to change what Jani did. It is
>> easier to deal with this minor breakage in 5.3.0 and then have a
>> consistent and clean configuration system. Continuing to add some
>> exceptions while hoping that "no weird things" are used
Hi!
That's exactly why I am reluctant to change what Jani did. It is
easier to deal with this minor breakage in 5.3.0 and then have a
consistent and clean configuration system. Continuing to add some
exceptions while hoping that "no weird things" are used is a bad idea
Do you see any problem w
hi,
On Fri, Sep 5, 2008 at 11:31 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
> Attached is the patch that does the following for php.ini parser:
> 1. \{LETTER} is literal inside "" now, whatever the letter is
> 2. \" is " inside "", with exception of:
> 3. foo="bar\"{NEWLINE} is pars
Hi!
Attached is the patch that does the following for php.ini parser:
1. \{LETTER} is literal inside "" now, whatever the letter is
2. \" is " inside "", with exception of:
3. foo="bar\"{NEWLINE} is parsed as bar\ - i.e. \ is allowed before
closing " but only if the line ends there (otherwise it
Hi!
I am writing to the list because there's a bug in the php snmp
extension that leaks memory. This bug has been reported by Federico
Cuello two months ago here: http://bugs.php.net/bug.php?id=45405
As you can see, Federico uploaded a patch that fixes the problem but
added a double free also two
Stanislav Malyshev wrote:
Hi!
Anyway, the fix is quite easy: Only allow \" and no other escapes. And
doing "foo\" should cause a syntax error.
Why? It's not like we don't know what the string "c:\foo\bar\" is
supposed to mean - why shouldn't it just work?
Feel free to fix it.
I'm not goin
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 y
Hi!
Anyway, the fix is quite easy: Only allow \" and no other escapes. And
doing "foo\" should cause a syntax error.
Why? It's not like we don't know what the string "c:\foo\bar\" is
supposed to mean - why shouldn't it just work?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTE
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 upgra
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 you
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 exac
Jani Taskinen schreef:
Hannes Magnusson wrote:
On Thu, Sep 4, 2008 at 22:43, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Johannes Schlüter kirjoitti:
...
php.ini-recommended, 5.3:
;
; Paths and Directories ;
;
; UNIX: "/path1:/path2"
;include_p
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 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
Hannes Magnusson wrote:
On Thu, Sep 4, 2008 at 22:43, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Johannes Schlüter kirjoitti:
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) ab
On Thu, Sep 4, 2008 at 22:43, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> Johannes Schlüter kirjoitti:
>>
>> 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 cha
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 correc
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
21 matches
Mail list logo
