Fixed in CVS.
zend_bailout() should work fine and shouldn't leak file descriptors because
the opened file is in the CG(open_files) list.
Andi
At 01:28 PM 2/1/2004 -0500, Ilia Alshanetsky wrote:
On February 01, 2004 01:08 pm, you wrote:
> Oh OK. As I mentioned in a previous email I'm not sure thi
On February 01, 2004 01:08 pm, you wrote:
> Oh OK. As I mentioned in a previous email I'm not sure this is the best way
> of doing the patch. It should be possible to bailout when the parse error
> is detected.
That was my initial concern as well, however the problem is that any earlier
attempts
At 12:42 PM 2/1/2004 -0500, Ilia Alshanetsky wrote:
On February 01, 2004 12:30 pm, Andi Gutmans wrote:
> I understand from the comments here that your patch wasn't very successful.
Original patch was incomplete, therefor I made 2 seperate patches (1 for php5
& 1 for php4) that augment the behaviour
On February 01, 2004 12:30 pm, Andi Gutmans wrote:
> I understand from the comments here that your patch wasn't very successful.
Original patch was incomplete, therefor I made 2 seperate patches (1 for php5
& 1 for php4) that augment the behaviour and fix the problem originally
reported by Rasmu
This sounds like a bug.
The behavior should be that unless there was a parse error
include/include_once should not halt but give a warning if the file doesn't
exist. require/require_once should halt if the file doesn't exist.
I understand from the comments here that your patch wasn't very success
The basic problem is as follows. If you have a parse error inside an included
or required file, the execution stops just for that file and continues for
the main script. The result is that normally a fatal (parse) error becomes a
warning. Consequently, it may result in undefined behavior since w
BTW take a look at zenderror(). This function is called when there's a
parse error.
It leads to an E_PARSE error and setting EG(exit_status) to 255.
If there is a problem, and I haven't quite understood what the problem is
today, that might be the place to fix it in.
Andi
At 11:17 PM 1/31/2004
I think I missed out on the original problem. What does the fix, fix? Isn't
a parse error automatically a fatal error?
If you revert your patch what won't work?
Andi
At 09:59 AM 1/30/2004 -0500, Ilia Alshanetsky wrote:
It seems like the only way to distinguish between a parse error and a
non-exis
The oirignal parse error messages not only tells you the filename but also the
line where the parse error occurs. The 2nd error (the one you referring to)
will tell you on which line the 'broken' file is being included.
Ex:
Parse error: parse error in /home/rei/PHP_CVS/php4/BUILD/inc2.inc on li
On Fri Jan 30, 2004 at 01:3752PM -0500, Ilia Alshanetsky wrote:
> +
> zend_error(E_ERROR, "Parse error inside included file.");
Is there any chance to include the name of the included file here?
--
- Martin
stat wouldn't work for URL includes.
> > + zend_file_handle file_handle;
> > + zend_bool can_open = zend_stream_open(inc_filename->value.str.val,
&file_handle TSRMLS_CC);
> > + zend_file_handle_dtor(&file_handle);
> > +
>
> wouldn't a stat be better suited here?
--
PHP Internals - PHP Runtime De
> + zend_file_handle file_handle;
> + zend_bool can_open =
> zend_stream_open(inc_filename->value.str.val, &file_handle TSRMLS_CC);
> + zend_file_handle_dtor(&file_handle);
> +
wouldn't a s
Here is the ZE1 revision.
Ilia
On January 30, 2004 01:21 pm, you wrote:
> On Fri, 30 Jan 2004, Ilia Alshanetsky wrote:
> > Here is the final revision of the patch for the situation, if there are
> > no last minute objections, it'll go in the CVS and we'll proceed with
> > RC2.
>
> Uh, that is a Z
On Fri, 30 Jan 2004, Ilia Alshanetsky wrote:
> Here is the final revision of the patch for the situation, if there are no
> last minute objections, it'll go in the CVS and we'll proceed with RC2.
Uh, that is a ZE2 patch. We are talking about PHP 4.3.5 RC2 here.
-Rasmus
--
PHP Internals - PHP
Here is the final revision of the patch for the situation, if there are no
last minute objections, it'll go in the CVS and we'll proceed with RC2.
Ilia
On January 30, 2004 12:37 pm, Rasmus Lerdorf wrote:
> On Fri, 30 Jan 2004, Ilia Alshanetsky wrote:
> > For include situation we need to see if t
On Fri, 30 Jan 2004, Ilia Alshanetsky wrote:
> For include situation we need to see if the error is due to the file not being
> there, in which case we can go forward with execution, or if the problem was
> due to a parse error, in which case we need to stop. The easiest way I saw of
> doing it
On January 30, 2004 12:03 pm, Rasmus Lerdorf wrote:
> Granted, I haven't looked closely at the code, but PHP knows that failure
> to open an include file is an E_WARNING not an E_ERROR. An E_WARNING
> should never cause script execution to terminate. If we already know it
> is non-fatal, why is t
On Fri, 30 Jan 2004, Ilia Alshanetsky wrote:
> It seems like the only way to distinguish between a parse error and a
> non-existant file for regular include() is by doing a zend_stream_open() upon
> failure to determine if the file is avaliable. If it is, then we return a
> parse error and if it
Alle 15:59, venerdì 30 gennaio 2004, Ilia Alshanetsky ha scritto:
> + if (can_open != SUCCESS) {
I didn't try to apply/compile the patch, I just read it, so perhaps I'm
wrong, but... shouldn't that != be a == ?
--
Cesare D'Amico - boss (@t) cesaredamico (dot) com
h
It seems like the only way to distinguish between a parse error and a
non-existant file for regular include() is by doing a zend_stream_open() upon
failure to determine if the file is avaliable. If it is, then we return a
parse error and if it does not we continue execution. This does add a smal
On Fri, 30 Jan 2004, Rasmus Lerdorf wrote:
> On Fri, 30 Jan 2004, Derick Rethans wrote:
>
> > On Fri, 30 Jan 2004, Rasmus Lerdorf wrote:
> >
> > > Remember that it is ok for an include to not find the file. We issue a
> > > warning and move on. It should in no way be treated as a fatal error.
>
On Fri, 30 Jan 2004, Derick Rethans wrote:
> On Fri, 30 Jan 2004, Rasmus Lerdorf wrote:
>
> > Remember that it is ok for an include to not find the file. We issue a
> > warning and move on. It should in no way be treated as a fatal error.
>
> But it should on a parse error in an include file, no
On Fri, 30 Jan 2004, Rasmus Lerdorf wrote:
> Remember that it is ok for an include to not find the file. We issue a
> warning and move on. It should in no way be treated as a fatal error.
But it should on a parse error in an include file, not?
Derick
--
PHP Internals - PHP Runtime Developmen
Ilia, I think there is a problem with your latest fixes on the 4_3 branch.
Stuff that used to work is now broken. Stuff like this:
main.php:
include 'inc1.inc';
inc1.inc:
@include 'inc2.inc';
If inc2.inc does not exist we now get an error similar to:
Warning: main(./lang/serendipity_la
24 matches
Mail list logo
