Guys,
Any chance this will make it into RC1 ??
--
Ard
Index: interbase.c
===
RCS file: /repository/php-src/ext/interbase/interbase.c,v
retrieving revision 1.194
diff -u -r1.194 interbase.c
--- interbase.c 21 Jan 2004 10:22:04 -
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
The following code
public function run(PHPUnit_Framework_Test $test) {
print_r($test);
$this->startTest($test);
print_r($test);
try {
$test->runBare();
}
catch (PHPUnit_Framework_AssertionFailedError $e) {
$th
On Fri, 30 Jan 2004, Stefan Walk wrote:
> Hi!
>
> There is an inconsistency in the Zend API (See #27097) so integers are
> reported as "integer" by zend_zval_type_name but "long" by
> zend_parse_arg_impl causing confusion for users not knowing C,
> the attached patch fixes it.
This is wrong, it's
Hi!
There is an inconsistency in the Zend API (See #27097) so integers are
reported as "integer" by zend_zval_type_name but "long" by
zend_parse_arg_impl causing confusion for users not knowing C,
the attached patch fixes it.
Stefan
--
Regards,
Stefan Walk
<[EMAIL PROTECTED]>
Index: zend_API.c
=
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
Hi,
currently playing around with the win32 build system, and I found that
nmake clean doesn't work (in fact nmake clean-sapi).
From Makefile:
clean-sapi:
@echo Cleaning SAPI
@for %D in ($(EXT_TARGETS)) do @del /F /Q $(BUILD_DIR)\%D > NUL
@for %D in ($(PECL_TARGETS)) do
Hi,
Here is the TSRM diff file in unified diff format.
I have used the command: cvs diff -uN
Regards,
Ananth.
>>> Marcus Boerger <[EMAIL PROTECTED]> 1/30/2004 12:31:43 PM >>>
Hello Ananth,
please provide a unified diff (cvs di -u) and we cannot accept
precompiler statements starting after colu
everything is loaded when libphp is initialized, right? so the answer is -
depends on if libphp is initialized or not. and I already said when is it
copied from the memory, and when is it re-executed from the disk...
On Fri, 30 Jan 2004, ashish b\ wrote:
> what about the extension module ? is
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
On Thu, 29 Jan 2004, Ananth Kesari wrote:
> Oops. I did not know that the system only accepts text/plain
> attachments. Here is the attachment for TSRM diff. This is in
> text format. I will send the diff for the whole project soon.
In unified diff pretty please? :) (cvs diff -u)
regards,
Derick
what about the extension module ? is it reloaded?
Regards
Ashish
shimi <[EMAIL PROTECTED]> wrote:
On Thu, 29 Jan 2004, ashish b\ wrote:
> Hello ,
> I have Apache compiled for Prefork MPM and PHP as Loadable module
> on Redhat LINUX 7.3.
> 1. I have a PHP extension module which is added in the "e
On Thu, 29 Jan 2004, ashish b\ wrote:
> Hello ,
> I have Apache compiled for Prefork MPM and PHP as Loadable module
> on Redhat LINUX 7.3.
> 1. I have a PHP extension module which is added in the "extension=mymodule.so"
> directive of php.ini.
> 2. Now when Apache starts it wil
Hello ,
I have Apache compiled for Prefork MPM and PHP as Loadable module
on Redhat LINUX 7.3.
1. I have a PHP extension module which is added in the "extension=mymodule.so"
directive of php.ini.
2. Now when Apache starts it will load the PHP module, which in turn will load the
Hello Ananth,
please provide a unified diff (cvs di -u) and we cannot accept
precompiler statements starting after column 0. You *must* keep
this in mind. For a full list of rules to follow you can visit
the file CODING_STANDARDS.
regards
marcus
Friday, January 30, 2004, 7:11:23 AM, you wrote:
28 matches
Mail list logo
