I actually must say we have a special kind of output buffering that saves
all the content in an array like structure and outputs all content at the
end. This way we managed to have our coders work in a rather C/C++ like way,
where they can modify the rendered content anywhere in a script. The fact
that the error gets detected twice is maybe a weirdness in our output
handler, but as you guys already said, this should be detected actually as a
parse error.
About the editor, it's weird. We use Eclipse Europa (PDT Tools),
because they integrate superb with our SVN2WEB development schema (instant
web publish, SVN backup) and the error isn't highlighted in Eclipse. The
manual tells nothing about such a thing.
It's actually a weird glitch. Why: because if a PHP project decides
it wants some weird control over the output buffer, like we do right here
with our "delay output until the script ends" ideology, chances for such a
typo to cause headaches is great. I can see projects rendered useless for a
time, until the code is scanned for such a weirdness.
All in all, thanks guys for the time you took testing this. It seems
I must revise our output-handler, and do something to our Eclipse PDT set-up
so it can detect this as an error.
-----Original Message-----
From: Thijs Lensselink [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 30, 2008 3:25 PM
Cc: php-general@lists.php.net
Subject: Re: [PHP] Is this a bug?
Jochem Maas wrote:
> T Lensselink schreef:
>> Catalin Zamfir Alexandru, DATAGRAM SRL wrote:
>>> Hello guys,
>>>
>>> I've been stalking on the list for some time. Didn't
>>> have
>>> anything to report/talk, until now. I have a code like this, maybe
>>> you guys
>>> can reproduce it, with output buffering started:
>>>
>>> Echo 'something';
>>>
>>> Echo 'another thing';
>>>
>>> Echo 'something <br />'\;
>>>
>>>
>>>
>>> What happens is that ANYTHING that was echo'ed until
>>> that \,
>>> will not reach the buffer. Although, this should actually be a Parse
>>> Error,
>>> it isn't, it just echoes what was echoed after the god damned \. It
>>> took me
>>> two hours to find this typo in the code .
>>>
>
> ouch.
> don't forget you can do:
>
> $> php - l yourscript.php
>
> to test for syntax errors (the warning does show up with this).
>
> additionally a good syntax highlighting editor can help you to spot
> stuff like this ... anything to stop the eyes from bleeding :/
>
>
>>>
>>> Can you guys reproduce the error? I can actually
>>> give you a
>>> link to the server where this code runs.
>>>
>>>
>>>
>> The script doesn't cause a parse error Instead it throws a warning.
>>
>> 'PHP Warning: Unexpected character in input: '\' (ASCII=92) state=1
>> in'
>>
>> Don't think it's a bug. And the reason there's no syntax error is
>> because the \ is a PHP
>> escape character.
>
> is this character ever valid as an escape character outside of a string?
> if it is that's news to me and if it isn't then really it is a bug ...
> it should be a straight up parse error ... chances are that it's down
> to limitations in the lexer?
>
> the output buffer handler that seems to be swallowing the warning every
> second request .... now that is weird.
I don't think it should be valid outside a string. But PHP seems to see
this different.
The only reason i could think of. Is that the \ somehow is a registered
symbol. So it throws
a non fatal E_COMPILE_ERROR. Could be a bug. That's for the guys on
internals to decide.
I'd also expect a parse error.
With output buffering enabled i still get the same warning on every request.
>
>>
>>
>>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
