On Wed, 2 Apr 2003, Andi Gutmans wrote:
> I'm not completely sure but from first glance at exif it is *completely*
> broken everywhere.
> You're not supposed to use zval_dtor() on parameters you get via
> zend_get_parameters_ex(). They are read-only as they are reference counted
> and are possibly
Here's another small little patch to fix imagepsextendfont() that sanity
checks the $extend parameter to make sure it's greater than zero.
Although less than zero "works" (i.e. it doesn't crash anything) it
really shouldn't be allowed.
John
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~
Okay... Here's the patch again. This is only one patch to correct the
error handling of the GD extension when using T1Lib... If someone really
wants me to post a second patch for the imagepscopyfont() function I
will, but it's a really trivial... I just suggested we throw a warning
instead of comp
On Wed, Apr 02, 2003 at 02:16:56PM +0200, Wojtek Meler wrote:
> Is there a way to tell PHP to not include some sources in CLI build?
> PHP_NEW_EXTENSION( mymodule , mymodule.c , nocli) doesn't work as I expected - it
> doesn't include extension in main/internal_functions_cli.c but it link mymodule
I'll separate the patches in a minute, but this isn't enabling the
function -- it's just throwing an E_WARNING (probably should
RETURN_FALSE too)... Otherwise you get a not-defined error.
John
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggesh
IMO we should not enable a buggy function, the output may be un expected and
if it results in memory corruption we could end with a fairly annoying and
hard to trace problem.
Ilia
On April 2, 2003 09:54 pm, John Coggeshall wrote:
> Here's a patch for the GD lib.. I'd like to commit this if ther
John,
Please separate the patches for review. I have a feeling that some
might not be desirable (the first), while other portions look good.
-Sterling
On Wed, 2003-04-02 at 21:54, John Coggeshall wrote:
> Here's a patch for the GD lib.. I'd like to commit this if there is no
> objection. It do
Here's a patch for the GD lib.. I'd like to commit this if there is no
objection. It does a few things:
1) Creates a warning for imagepscopyfont()... It's in the docs and right
now its completely commented out in the source... For BC this really
should not just completely disappear (even if T1Lib
N/M... ./buildconf is a wonderful thing... (whoops)
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
>-Original
I just checked out a copy of HEAD and can't build PHP5, it looks like
some changes were made to rename everything from php4->php5 and there
are still some php4 references floating around that end up in the
Makefile:
[EMAIL PROTECTED] ~/php5]$ make
make: *** No rule to make target `libphp4.la', ne
On Wed, 2 Apr 2003, Matt Jarjoura wrote:
> to create a template engine extension in C that runs standard on all PHP
> engines. Instead of running smarty here and another one there, I am
> in the process of building an extension that handles all of it fast and
> hopefully to become standardized.
Co
> xml_parser_create($maxs);
I can't reproduce this one and I don't really see how passing a long
string to that code could be a problem.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to create a template engine extension in C that runs standard on all PHP
engines. Instead of running smarty here and another one there, I am
in the process of building an extension that handles all of it fast and
hopefully to become standardized.
--
PHP Internals - PHP Runtime Development Maili
On Wed, 02 Apr 2003, Andrei Zmievski wrote:
> + if (EG(active_namespace) != ns) {
> + orig_namespace = EG(active_namespace);
> + EG(active_namespace) = ns;
> + CG(class_table) = &ns->class_table;
> + }
> + register_class = zend_register_internal_class
Contributing an XML_NITF class to PEAR, I need access to the portion of the PEAR/XML/
tree and whatever access I need to add DocBook information for the class in the PEAR
repository.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> >We don't want to apply this doc comment to class Bar, so it needs to be
> >reset on every statement, basically. Isn't that right?
>
> Probably, yes. I think Alan mentioned it.
So it would be enough to reset it in unticked_statement rule?
-Andrei
At 18:51 02/04/2003, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional
rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a gl
On Wed, 02 Apr 2003, Zeev Suraski wrote:
> I don't really like the idea of cluttering the parser with additional rules
> if it's not really necessary. I think that the idea proposed by Alan is
> actually the best way to go (keep the last comment in a global, use and
> reset it in the next relev
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> How about:
> if ($a
> /**
> $a is great variable */
> || $b) {
>
> }
>
> I'm sure I can find other more realistic examples which would break. I
> don't know why I didn't think of it before but I think having this in the
> parser is impossible.
At 18:38 02/04/2003, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strate
At 10:41 AM 4/2/2003 -0500, Andrei Zmievski wrote:
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> Oh, I didn't think of that. You are completely right. This is definitely a
> problem. Andrei's patch returns a token for /** */ on the parser level so
> only places which are allowed to have this work.
> T
At 10:38 AM 4/2/2003 -0500, Andrei Zmievski wrote:
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our
On Wed, 02 Apr 2003, Andi Gutmans wrote:
> Oh, I didn't think of that. You are completely right. This is definitely a
> problem. Andrei's patch returns a token for /** */ on the parser level so
> only places which are allowed to have this work.
> This sounds like a serious flaw because any place
> >This problem bites just about any places where people used /** */ as
> >comments.
> >For example:
> >if ($a > 5) { /** This is a smart check *.
> >}
> >
> >IMO, we can't break BC this badly.
>
> Ah, that's right. We probably need to rethink our strategy then, and tie
> doc comments to the re
On Wed, 02 Apr 2003, Lance Lovette wrote:
> Can the purpose of doc comments be clarified? Why aren't class variables
> important enough to document? I think everything exposed by a class -
> variables, methods, constants, etc. - are all equally important and should
> be documented.
The problem is
Can the purpose of doc comments be clarified? Why aren't class variables
important enough to document? I think everything exposed by a class -
variables, methods, constants, etc. - are all equally important and should
be documented.
> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL
On Wed, 02 Apr 2003, Alan Knowles wrote:
> http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
>
> removed the T_DOC_COMMENT from being ignored by zendlex -
>
> looks like at the moment, optional_doc_comment is splattered all over
> the parser.
>
> the other way
Is there a way to tell PHP to not include some sources in CLI build?
PHP_NEW_EXTENSION( mymodule , mymodule.c , nocli) doesn't work as I expected - it
doesn't include extension in main/internal_functions_cli.c but it link mymodule.o
to sapi/cli/php.
regards,
Wojtek
--
PHP Internals - PHP Runti
Translating the spanish documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2003-04-02 at 12:26, Rob Richards wrote:
> Patch didnt get attached in last message.
>
> It can be found here: http://www.digarc.com/php_domxml.c.diff
applied. thanks
chregu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Patch didnt get attached in last message.
It can be found here: http://www.digarc.com/php_domxml.c.diff
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This patch fixes Bug #22774 PHP crashes when exiting.
All it does is move the registration of the php_free_xml_doc destructor to
the end of the list, so it is called after destroying nodes and attributes
in the instances where the domxml extension is loaded via a dl() call.
It seems the only time
The attached source presents a multiplication routine with
built-in overflow detection. For x86/GCC, we can avoid
floating point arithmetic by using a small assembler
fragment. Support for other platforms can be added as
necessary.
There are two distinct uses for this in
At 07:30 02.04.2003, Andi Gutmans wrote:
I'm not completely sure but from first glance at exif it is *completely*
broken everywhere.
You're not supposed to use zval_dtor() on parameters you get via
zend_get_parameters_ex(). They are read-only as they are reference counted
and are possibly pointe
http://cvs.php.net/diff.php/ZendEngine2/zend_compile.c?r1=1.403&r2=1.404&ty=h&num=10
removed the T_DOC_COMMENT from being ignored by zendlex -
looks like at the moment, optional_doc_comment is splattered all over
the parser.
the other way to do this (is what phpcodedoc does) is just to
remembe
35 matches
Mail list logo
