That's what I figured. throw is a language construct.
However, from the manual (http://php.net/exit):
void exit ( int status)
Note: This is not a real function, but a language construct.
Why does
$x || exit;
work without a parse error?
Thanks,
Jason Garber
At 6/17/2004 10:22 AM +0400, An
On Thu, 17 Jun 2004 02:17:26 -0400
Jason Garber <[EMAIL PROTECTED]> wrote:
> Consider the following:
> Why is this?
Take a look at the bug #28727:
http://bugs.php.net/?id=28727
---
WBR,
Antony Dovgal aka tony2001
[EMAIL PROTECTED] || [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
Consider the following:
$x = FALSE;
$x || throw new exception('Some Assertion');
I get the following Parse Error:
error: parse error, unexpected T_THROW in /home/.../Z_Record.php on line 153
However, this code produces no errors..
$x = FALSE;
$x || exit;
Why is this?
Thanks,
Jason Garber
--
PHP Int
On Wed, 16 Jun 2004, Marc Richards wrote:
> Going form Apache1 to Apache2, aside form filters (which you mentioned
> in bug 27583) there is the default inclusion of mod_ssl and mod_ldap,
> better Internationalization features, mod_perl 2.0 (which ONLY works
> with Apache2), Subversion via WebDAV, a
Rasmus Lerdorf wrote:
[snip]
The problem here is not as simple as people like to make it sound. Time
and time again I see the /. mentality where people berate PHP developers
for being stupid and stubborn for not just "fixing PHP" so it is stable
and robust with Apache2.
I have explained this a num
At 08:45 AM 6/16/2004 -0700, Sterling Hughes wrote:
I'll buy that alloca() is harmless in the places the executor uses it
(*), php segvs on highly recursive functions, worrying about overly
long function names won't keep anyone up at night. But the real issue
is the other areas ilia mentions, wher
Sara Golemon wrote:
iirc, Linux treats both int and long as 64bit datatypes so it'd be a
non-issue there. The concern is platforms which treat int and long as
different sizes. Watch your configure output for:
Actually, (un)signed ints are 32-bit on all 64-bit platforms I know of
(Linux/[Free]BSD
Well if you wish to continue adding more challenges to solving your
goal, you could add in the latest CVS versions of gcc as well.
Honest, your best bet to start debugging this is to place PHP5+PGPGACL
into a stable environment. If it doesn't reproduce there, introduce a
semi-stable environmen
> 1. Does that mean PHP on 64-bit is declared not safe for Production
> use?
>
It means it's not as heavily tested as on 32bit platforms :)
> 2. Will it be safe on Linux AMD64, if we compiled PHP with
> CFLAGS="-m32" ?
>
iirc, Linux treats both int and long as 64bit datatypes so it'd be a
non-is
-- On Wednesday, June 16, 2004 2:49 PM -0700 Dan Kalowsky <[EMAIL PROTECTED]> wrote:
A good start would be to move away from a completely developer environment like you're using. I'd suggest either working with PHP5 or Apache2-dev, but not both at the same time. That should help you narrow thing
A good start would be to move away from a completely developer environment
like you're using. I'd suggest either working with PHP5 or Apache2-dev,
but not both at the same time. That should help you narrow things down a
bit more. In reality, I'd narrow to Apache1 as well if you're trying to
hi all,
i'd posted this on the phpgacl list, and a kind soul there suggested to try here ...
i'm looking for any/help help in starting to debug this.
thx,
richard
Segfault, so I'm assuming its a PHP5 issue. I haven't actually tested
phpGACL on PHP5 yet, but in theory it should work, as PHP5 is back
While this is being fixed:
1. Does that mean PHP on 64-bit is declared not safe for Production
use?
2. Will it be safe on Linux AMD64, if we compiled PHP with
CFLAGS="-m32" ?
I have noticed on both release of PHP4.3.7 & PHP5.0.0RC3, there are some
failures during "make test", if compiled wit
Hello Stanislav,
Wednesday, June 16, 2004, 10:16:17 AM, you wrote:
AV>>>I can't find any serious reason to apply the pathes into the current
AV>>>PHP4 and PHP5 versions.
> PHP5 is in freeze now. Meaning, no changes are done unless they are
> absolutely critical. The reason is that we want PHP5
Hello Ray,
Wednesday, June 16, 2004, 4:26:26 PM, you wrote:
> Hi all,
[]
- NOTHING stops you from passing NULL to functions.
- Typhints are a shortcut for an 'instanceof'`test
- now try NULL instanceof stdclass:
php-cvs $ php -r 'var_dump(NULL instanceof stdclass);'
bool(false)
- what
On Wed, 16 Jun 2004, Hartmut Holzgraefe wrote:
> It should still find the *last* emtpy string, not the first,
> shouldn't it? ;)
Yup. I think we've now spent more time discussing this function than
people have spent using it. :)
-adam
--
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoi
Ard Biesheuvel wrote:
Hartmut Holzgraefe wrote:
Adam Maccabee Trachtenberg wrote:
Logically, it would probably be best to return 0 because that's where
the first empty string occurs.
this is strrchr(), not strchr() ;)
Actually it's strrpos(), not str[r]chr() [look at Alexander's code],
which _ha
Hartmut Holzgraefe wrote:
Adam Maccabee Trachtenberg wrote:
Logically, it would probably be best to return 0 because that's where
the first empty string occurs.
this is strrchr(), not strchr() ;)
Actually it's strrpos(), not str[r]chr() [look at Alexander's code],
which _has_ been rewritten in
Adam Maccabee Trachtenberg wrote:
Logically, it would probably be best to return 0 because that's where
the first empty string occurs.
this is strrchr(), not strchr() ;)
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Alexander Valyalkin wrote:
> Today I've revised strrchr() function in PHP4.3.7 sources.
> It wasn't binary-safe. For example:
... which is probably why it has already been completely rewritten in PHP 5.
--
Ard
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
On Wed, 16 Jun 2004, Hartmut Holzgraefe wrote:
> > 1) strrpos('abcd', '') returns 4. Expected FALSE
> Although one could argue whether searching for empty
> strings makes sense at all the result is not completely
> wrong. There *is* an empty string at the end of the haystack ...
And at the beginn
Alexander Valyalkin wrote:
Today I've revised strrchr() function in PHP4.3.7 sources.
It wasn't binary-safe. For example:
1) strrpos('abcd', '') returns 4. Expected FALSE
Although one could argue whether searching for empty
strings makes sense at all the result is not completely
wrong. There *is* a
On Wed, 16 Jun 2004, Alexander Valyalkin wrote:
> On Wed, 16 Jun 2004 07:05:32 -0700 (Pacific Standard Time), Rasmus Lerdorf
> <[EMAIL PROTECTED]> wrote:
>
> >> As Alexander's initial re-implementation of crc32() was broken on 64-bit
> >> architectures, I think this is a very good point.
> >
>
Hi,
seems some parts... especially sqlite are not 64bit safe.
If you want to do something productive go out and search for
zend_parse_parameter calls where l is not writing to a long (NOT int)
and where the strlen of a s is not written into an int.
F.e. in sqlite there seems to be several places
On Wed, 16 Jun 2004 07:05:32 -0700 (Pacific Standard Time), Rasmus Lerdorf
<[EMAIL PROTECTED]> wrote:
As Alexander's initial re-implementation of crc32() was broken on 64-bit
architectures, I think this is a very good point.
And his stripslashes() "improvement" actually broke backward
compatib
On Wed, 16 Jun 2004 16:35:04 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
Alexander Valyalkin wrote:
On Wed, 16 Jun 2004 12:03:36 +0200, Ard Biesheuvel <[EMAIL PROTECTED]>
wrote:
Have you tested my initial re-implementation of crc32() on 64-bit
architectures?
No, but I don't have to:
re
So, oddly enough while responding to this, gmail is showing me Zend
advertisements - just thought you should know you are getting your
money's worth :)
I'll buy that alloca() is harmless in the places the executor uses it
(*), php segvs on highly recursive functions, worrying about overly
long fun
Today I've revised strrchr() function in PHP4.3.7 sources.
It wasn't binary-safe. For example:
1) strrpos('abcd', '') returns 4. Expected FALSE
2) strrpos("a\0abcde", 'a') returns 6. Expected 2
3) strrpos("a\0bcde", "\0") returns 6. Expected 1
4) strrpos('', '\0') returns 0. Expected FALSE
My versi
On June 16, 2004 12:15 pm, Ard Biesheuvel wrote:
> Ilia Alshanetsky wrote:
> > PHP5/Interbase: too many arguments passed to some functions.
>
> The function in question alloca()tes a 4 pointers times the number of
> args which is kept in an unsigned short. This means the allocated memory
> can at m
Ard Biesheuvel wrote:
Ilia Alshanetsky wrote:
PHP5/Interbase: too many arguments passed to some functions.
The function in question alloca()tes a 4 pointers times the number of
args which is kept in an unsigned short. This means the allocated memory
can at most be 1M.
While this seems a lot to
Ilia Alshanetsky wrote:
PHP5/Interbase: too many arguments passed to some functions.
The function in question alloca()tes a 4 pointers times the number of
args which is kept in an unsigned short. This means the allocated memory
can at most be 1M.
While this seems a lot to allocate on the stack,
Alexander Valyalkin wrote:
On Wed, 16 Jun 2004 12:03:36 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
Have you tested my initial re-implementation of crc32() on 64-bit
architectures?
No, but I don't have to:
register unsigned long int crc = ~0ul;
... so crc = 0x
do {
Hi all,
With these changes, im not entirely sure how one is supposed to indicate
that the given argument to a method is not valid, not set, default, etc...
I have been using PHP5 for some time now, but i can't say im up to speed
on the internal technicalities of PHP, but i feel that typehinting
On Wed, 16 Jun 2004, Ard Biesheuvel wrote:
> Lester Caine wrote:
> > On the other hand, if code IS working stably then it may be better to
> > leave it alone. I'm not saying don't tidy up code, but ALL the tests
> > against a change need to be in place before a change is applied to the
> > live co
Alexander Valyalkin wrote:
On Wed, 16 Jun 2004 00:41:19 +0300, Andrey Hristov <[EMAIL PROTECTED]> wrote:
Privet Alex,
is it possible to show some results from benchmarking?
>
Just compile my standalone test & view results :)
As noted before: standalone benchmarks can only tell you whether ot not
On Jun 16, 2004, at 4:06 AM, Alexander Valyalkin wrote:
On Tue, 15 Jun 2004 21:56:37 +0100, Lester Caine <[EMAIL PROTECTED]>
wrote:
Once PHP5 is out - THEN the sorts of fixes Alexander is suggesting
could be looked at - but not until then.
Once PHP5 is out - THEN all of my fixes will safely forg
Andi,
Well, majority of the places where it is used right now can be abused through
user input.
PHP 4/5: overly long constant names defined(str_repeat("a", 1024 * 1024 * 6));
PHP5: overly long class & method names
PHP5: overly long function name
PHP5/Interbase: too many arguments passed to some
On Wed, 16 Jun 2004 12:03:36 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
As Alexander's initial re-implementation of crc32() was broken on 64-bit
architectures, I think this is a very good point.
Have you tested my initial re-implementation of crc32() on 64-bit
architectures?
--
Using Opera
Jan Lehnardt wrote:
I have seem this questions been asked many times in a few mail list.
Someone should post this reply into a FAQ page or the Manual in
www.php.net
I am about to commit this to the installation chapter of the manual.
Looking forward to it :)
--
Lester Caine
Lester Caine wrote:
On the other hand, if code IS working stably then it may be better to
leave it alone. I'm not saying don't tidy up code, but ALL the tests
against a change need to be in place before a change is applied to the
live code, and in some cases it is worth remembering that PHP *IS*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 16 Jun 2004, at 11:35, Joseph Lee wrote:
I have seem this questions been asked many times in a few mail list.
Someone should post this reply into a FAQ page or the Manual in
www.php.net
I am about to commit this to the installation chapter of the
Well written & well explain Rasmus.
I have seem this questions been asked many times in a few mail list.
Someone should post this reply into a FAQ page or the Manual in
www.php.net
Joe Lee.
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 200
BS>>Well, I'm not quite sure of this. Almost EVERY new piece of code
BS>>Alexander posted on php.internals was followed by one or more
BS>>revisions within one or two days! For me, this means that the chance
BS>>that the 'final' code he gives most likely isn't perfect at all...
The point is, howev
Stanislav Malyshev wrote:
> I understand that you are fully confident that you code would always
work.
Well, I'm not quite sure of this. Almost EVERY new piece of code
Alexander posted on php.internals was followed by one or more revisions
within one or two days! For me, this means that the ch
On Wed, 16 Jun 2004 11:20:33 +0300
"Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jun 2004 12:11:07 +0400, Antony Dovgal
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 16 Jun 2004 11:06:31 +0300
> > "Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
> >
> >> I can't find any serious rea
I don't think it's a good idea to access s[-1] even if the logic works.
This should be fixed IMO.
At 10:30 PM 6/14/2004 +0200, Christian Schneider wrote:
Ilia Alshanetsky wrote:
Do you have an example script that can be used to reproduce the supposed
memory access violation?
The function php_bas
On Wed, 16 Jun 2004 11:11:25 +0300
"Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
> On Wed, 16 Jun 2004 00:41:19 +0300, Andrey Hristov <[EMAIL PROTECTED]>
> wrote:
>
> > Privet Alex,
> > is it possible to show some results from benchmarking?
> >
> > Thanks a lot,
> > Andrey
> >
>
> Just comp
On Wed, 16 Jun 2004 12:11:07 +0400, Antony Dovgal <[EMAIL PROTECTED]>
wrote:
On Wed, 16 Jun 2004 11:06:31 +0300
"Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
I can't find any serious reason to apply the pathes into the current
PHP4 and PHP5 versions.
Yup. Me too.
I can't find any reason to ap
On Wed, 16 Jun 2004 10:55:56 +0300
"Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jun 2004 22:48:35 +0200, Bert Slagter <[EMAIL PROTECTED]>
> wrote:
>
> As you could notice, I provide majority of my patches with standalone
> test applications, which could be used to track possible
Ilia,
alloca() is very important for the executor loop and functions which where
performance is very important (mainly the Zend Engine).
I don't see any convincing reason not to use it in the way it is being used
today. If there are any specific places you find problematic and want to
discuss le
AV>>I can't find any serious reason to apply the pathes into the current
AV>>PHP4 and PHP5 versions.
PHP5 is in freeze now. Meaning, no changes are done unless they are
absolutely critical. The reason is that we want PHP5 to be sufficiently
tested and be confident that it is working before relea
On Wed, 16 Jun 2004 00:41:19 +0300, Andrey Hristov <[EMAIL PROTECTED]> wrote:
Privet Alex,
is it possible to show some results from benchmarking?
Thanks a lot,
Andrey
Just compile my standalone test & view results :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
--
PHP In
On Wed, 16 Jun 2004 11:06:31 +0300
"Alexander Valyalkin" <[EMAIL PROTECTED]> wrote:
> I can't find any serious reason to apply the pathes into the current
> PHP4 and PHP5 versions.
Yup. Me too.
I can't find any reason to apply not tested patches to both stable &
unstable branches.
---
WBR,
Anton
On Tue, 15 Jun 2004 21:56:37 +0100, Lester Caine <[EMAIL PROTECTED]>
wrote:
Once PHP5 is out - THEN the sorts of fixes Alexander is suggesting could
be looked at - but not until then.
Once PHP5 is out - THEN all of my fixes will safely forgotten, on my
opinion :)
I can't find any serious reaso
On Tue, 15 Jun 2004 22:48:35 +0200, Bert Slagter <[EMAIL PROTECTED]> wrote:
Thomas Goyne wrote:
As a user, I personally see placing new features over making old
features work better a large mistake. Perhaps that was necessary back
in the days of PHP3, but its been a very long time since I've
Lester Caine wrote:
> The only difficulty is
> " Do not use Apache 2.0 and PHP in a production environment neither on
> Unix nor on Windows."
> in the manual tells my customers that I should not be!
There is also good Rasmus' explanation at
http://bugs.php.net/bug.php?id=27583
Jakub Vrana
--
PHP
On Wed, 16 Jun 2004, Curt Zirzow wrote:
> * Thus wrote Christian Schneider ([EMAIL PROTECTED]):
> > Lester Caine wrote:
> > >Well is it approved for use with Apache2?
> >
> > Correct me if I'm wrong but my understanding is that the PHP core is
> > approved with Apache2 in threaded mode.
>
> If my
On Tue, 15 Jun 2004, Lester Caine wrote:
> Steph wrote:
> >>The next question is - are both PHP4 and PHP5 going to be run in
> >>parallel, like Apache 1 and 2 so that neither gets finished ;)
> >
> >
> > Darn.. y'mean PHP 4 isn't finished? ;)
>
> Well is it approved for use with Apache2?
That ha
On Tue, 15 Jun 2004, Scott MacVicar wrote:
> If Alexander could provide proper benchmarks from PHP rather than
> separate C++ files and if the strings changes could be tested thoroughly
> with multiple values.
>
> I think improving performance would be great, there isn't a developer
> devoted to i
59 matches
Mail list logo
