At 10:17 02/04/2003, Andi Gutmans wrote:
At 10:13 AM 4/2/2003 +0300, Zeev Suraski wrote:
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> w
At 10:13 AM 4/2/2003 +0300, Zeev Suraski wrote:
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are fu
At 09:23 02/04/2003, Andi Gutmans wrote:
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are functions not variables.
Hm, so my PHP 4-styli
At 08:16 AM 4/2/2003 +0200, Sascha Schumann wrote:
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are functions not variables.
Hm, so my PHP 4-stylish code would cause a parse error, if it
On Wed, 2 Apr 2003, Sascha Schumann wrote:
> On Wed, 2 Apr 2003, Andi Gutmans wrote:
>
> > AFAIK, doc comments are for classes and functions only. I think this is
> > what's important because interfaces are functions not variables.
>
> Hm, so my PHP 4-stylish code would cause a parse error,
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are functions not variables.
Hm, so my PHP 4-stylish code would cause a parse error, if it
contained a valid character like a "*" after t
AFAIK, doc comments are for classes and functions only. I think this is
what's important because interfaces are functions not variables.
Andi
At 07:50 AM 4/2/2003 +0200, Sebastian Bergmann wrote:
Current HEAD:
works, but
causes
Parse error: parse error, unexpected T_VAR,
That's where the "I'm not completely sure" comes in. I just took a quick
glance and saw three zval_dtor()'s. I didn't see those were the only ones.
We need to make sure people don't make such mistakes (possibly search the
whole tree for zval_dtor()'s). I have a feeling this problem exists in
va
Current HEAD:
works, but
causes
Parse error: parse error, unexpected T_VAR, expecting T_FUNCTION
in e:\var.php on line 5
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wish
Marcus Börger wrote:
Did 1.875b work
No. At the moment two bison developers, Akim Demaille and Paul Eggert,
are looking into the issue of why bison 1.875+ generated parsers crash
PHP.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you?
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> I'm not completely sure but from first glance at exif it is *completely*
> broken everywhere.
What do you mean completely broken everywhere? The dtor stuff is only in
the exif_thumbnail() function.
-Rasmus
--
PHP Internals - PHP Runtime Development Mai
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 pointed to by other variables too. You should u
> It was brought to my attention that this code is legal in PHP 4:
>
> function foo($param = 'test')
> {
> global $$param;
> echo $$param;
> }
>
> $test = 'bar';
> foo(); // prints bar
>
> Is this a feature or a bug? (Should we support this syntax in
> phpDocumentor, or might it change in
Hi,
It was brought to my attention that this code is legal in PHP 4:
function foo($param = 'test')
{
global $$param;
echo $$param;
}
$test = 'bar';
foo(); // prints bar
Is this a feature or a bug? (Should we support this syntax in
phpDocumentor, or might it change in php 5?)
Greg
--
php
This test is failing because of the good old-well known floating point
drift issue.
4.9 + 0.1 > 5.0
The kludge attached below "solves" it, but... well... it's a kludge. It
basicly adds (or subtracts) the smallest measurable piece of a double
during the comparison step (so as to not alter the act
At 22:45 01.04.2003, joe at recompiled dot org wrote:
ID: 23007
User updated by: joe at recompiled dot org
Reported By: joe at recompiled dot org
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Mandrake 9.1
PHP Version:
Alle 19:45, martedì 1 aprile 2003, Rasmus Lerdorf ha scritto:
> Never mind, I see it.
Just for the sake of curiosity (I'm not a really clever C
programmer)... do you have a minute to explain to us too? Thanks :)
Ciao
:ce
--
"Computer Science is as much about computers as Astronomy is abou
At 20:55 01.04.2003, Sebastian Bergmann wrote:
Moriyoshi Koizumi wrote:
> moriyoshi Sat Mar 29 10:54:19 2003 EDT
>
> Modified files:
> /php4 configure.in
> Log:
> Improved bison check
checking for bison... bison -y
checking bison version... ./configure: test: 875b: int
Moriyoshi Koizumi wrote:
> moriyoshi Sat Mar 29 10:54:19 2003 EDT
>
> Modified files:
> /php4 configure.in
> Log:
> Improved bison check
checking for bison... bison -y
checking bison version... ./configure: test: 875b: integer expression
expected 1.875b (ok)
--
On Tue, 1 Apr 2003, Sascha Schumann wrote:
[EMAIL PROTECTED] tal $ php -a
Interactive mode enabled
Extending the list, now also testing with an empty array().
>
> i18n_convert('','',$mina);
> mb_convert_encoding('','',$mina);
> array_pad($mina,$maxn,$maxn);
> setlocale($maxn
Never mind, I see it.
On Tue, 1 Apr 2003, Rasmus Lerdorf wrote:
> > socket_iovec_alloc($maxn,$maxn,$maxn);
>
> Didn't I fix that one? Where is the overflow in this:
>
> int i, j, argc = ZEND_NUM_ARGS();
>
> if(argc>65536) {
> WRONG_PARAM_COUNT;
> }
>
>
Howdy,
In case you didn't notice try phpinfo() today . . .
Happy foolin' . . .
Cheers,
JPS
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> socket_iovec_alloc($maxn,$maxn,$maxn);
Didn't I fix that one? Where is the overflow in this:
int i, j, argc = ZEND_NUM_ARGS();
if(argc>65536) {
WRONG_PARAM_COUNT;
}
args = emalloc(argc*sizeof(zval**));
if (argc < 1 || zend_get_parameters_array_ex(
Hi,
I don't know if this is the right list to use for this. Anyway.
I have created RPM packages of PHP 4.3.1 with a lot of modules. The
packages are based on Troels Arvin's work, but don't blame him for any
mistakes made by me ;-)
I only have a Red Hat 7.3 machine to build on. If anyone can give
It didn't _even_ "sound" official.
The wording really lacks that little "press release" touch.
Better luck next year. ;)
Xavier.
On Tue, 2003-04-01 at 02:12, [EMAIL PROTECTED] wrote:
> Nice try !
>
> --
> Regards.
> M.CHAILLAN Nicolas
> [EMAIL PROTECTED]
> www.WorldAKT.com Hébergement de sites i
Extending the list, now also testing with an empty array().
i18n_convert('','',$mina);
mb_convert_encoding('','',$mina);
array_pad($mina,$maxn,$maxn);
setlocale($maxn,$mina,$maxn);
unregister_tick_function($maxn);
xml_parser_create($maxs);
> bcsub('',$maxn);
>
And some more (the 13 should have been 0 in the script):
bcsub('',$maxn);
dbase_open($maxs,$maxn);
exif_imagetype($maxn);
> ob_start();
>
> socket_iovec_alloc($maxn,$maxn,$maxn);
>
> exif_thumbnail('',$maxs,$maxn);
>
> mb_ereg('',$maxs,$maxn);
>
> mb_ereg_match
Here are some further functions which directly or indirectly
cause a segfault. In some cases, the prior function
invocation screwed up the engine internals, so that the next
function call resulted in a segfault.
How to reproduce:
1. wget http://schumann.cx/do_crash.txt
s
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
29 matches
Mail list logo
