RE: [PHP-DEV] Possible problem in the parser

[Ford, Mike [LSS]]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 13 March 2003 19:33
> To: Ford, Mike [LSS]
> Cc: 'Andrey Hristov'; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Possible problem in the parser
> 
> 
> At 14:58 13.03.2003, Ford, Mike   [LSS] wrote:
> 
> >Just to make this completely clear, in left-associative PHP
> >
> >b = a==1? 4:a==2? 5:6;
> >
> >is equivalent to
> >
> >b = (a==1? 4:a==2)? 5:6;
> 
> 
> NO it is not equal. Either '==' has higher precedence OR '?:' has.
> See one of my previous mails where i showed where the error is.

Yes, it is -- believe me, I've researched this extensively.  It is NOT about 
precedence, but associativity.  If you want me to be totally completist about this:

Starting from:

   b = a==1? 4:a==2? 5:6;

precedence rules make this equivalent to:

   b = (a==1)? 4:(a==2)? 5:6;

but this is still ambiguous -- which ?: phrase do you evaluate first?  Associativity 
provides the answer: in PHP, where ?: is left associative (i.e. the left most ?: is 
evaluated first), the result is equivalent to:

   b = ((a==1)? 4:(a==2))? 5:6;

On the other hand, in c, where ?: is right associative, the equivalent is:

   b = (a==1)? 4:((a==2)? 5:6);

which, apart from the additional (unnecessary) parentheses around the == comparisons, 
is exactly what I said before.

QED

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Possible problem in the parser

[Andi Gutmans]

You are right that it doesn't behave the same as C. However, personally 
although it might have been better for it to work like C I don't think it's 
a good idea to change it now. First of all it would break backwards 
compatibility in a way which would be hard for people to find where the bug 
is and how to fix it. Secondly, not meaning to insult anyone here, but I 
think people who write such code without using parentheses should improve 
their coding style :)

Andi

At 12:01 PM 3/14/2003 +, Ford, Mike   [LSS] wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 13 March 2003 19:33
> To: Ford, Mike [LSS]
> Cc: 'Andrey Hristov'; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Possible problem in the parser
>
>
> At 14:58 13.03.2003, Ford, Mike   [LSS] wrote:
>
> >Just to make this completely clear, in left-associative PHP
> >
> >b = a==1? 4:a==2? 5:6;
> >
> >is equivalent to
> >
> >b = (a==1? 4:a==2)? 5:6;
>
>
> NO it is not equal. Either '==' has higher precedence OR '?:' has.
> See one of my previous mails where i showed where the error is.
Yes, it is -- believe me, I've researched this extensively.  It is NOT 
about precedence, but associativity.  If you want me to be totally 
completist about this:

Starting from:

   b = a==1? 4:a==2? 5:6;

precedence rules make this equivalent to:

   b = (a==1)? 4:(a==2)? 5:6;

but this is still ambiguous -- which ?: phrase do you evaluate 
first?  Associativity provides the answer: in PHP, where ?: is left 
associative (i.e. the left most ?: is evaluated first), the result is 
equivalent to:

   b = ((a==1)? 4:(a==2))? 5:6;

On the other hand, in c, where ?: is right associative, the equivalent is:

   b = (a==1)? 4:((a==2)? 5:6);

which, apart from the additional (unnecessary) parentheses around the == 
comparisons, is exactly what I said before.

QED

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211
--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Possible problem in the parser

[Jani Taskinen]

On Fri, 14 Mar 2003, Andi Gutmans wrote:

>You are right that it doesn't behave the same as C. However, personally 
>although it might have been better for it to work like C I don't think it's 
>a good idea to change it now. First of all it would break backwards 
>compatibility in a way which would be hard for people to find where the bug 
>is and how to fix it. Secondly, not meaning to insult anyone here, but I 
>think people who write such code without using parentheses should improve 
>their coding style :)

Amen. :)

--Jani


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Possible problem in the parser

[Ford, Mike [LSS]]

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2003 14:50
> 
> You are right that it doesn't behave the same as C. However, 
> personally 
> although it might have been better for it to work like C I 
> don't think it's 
> a good idea to change it now. First of all it would break backwards 
> compatibility in a way which would be hard for people to find 
> where the bug 
> is and how to fix it. Secondly, not meaning to insult anyone 
> here, but I 
> think people who write such code without using parentheses 
> should improve 
> their coding style :)

Oh, I totally agree.  My original response was to a query as to whether the
PHP behaviour was a bug -- so I simply pointed out (in some detail!) that,
although different from c, it *did* conform to the precedence and
associativity documented in the PHP manual.

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> large patch and probably no one got to check it all out). Then, I
> reposted them (and sent then directly to you, Dave!) a few days ago.

And I got all but the three files merged that are probably causing his
problem too - sigh-

Sorry but I don't commit what I don't understand, and the three streams
files needed some more understanding on my part. In those areas the php5
head differs quite a bit from the 4_3 stream.

And on top of that I got diverted by a bug in the session stuff too.

Well as I always say in my volunteer posts - if you don't like the job I am
doing - cut my pay, if you like what I am doing you can double it - either
way the result is the same :-)

I will try to get the file descriptors stuff in by early next week.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Please coordinate with me on streams issues; if some 64bit oses declare
descriptors as longs rather than ints, then we could have a bigger job
on our hands (similar to the mess with socket types under win32).

--Wez.

On Fri, 14 Mar 2003, David Hill wrote:

> > CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> > large patch and probably no one got to check it all out). Then, I
> > reposted them (and sent then directly to you, Dave!) a few days ago.
>
> And I got all but the three files merged that are probably causing his
> problem too - sigh-
>
> Sorry but I don't commit what I don't understand, and the three streams
> files needed some more understanding on my part. In those areas the php5
> head differs quite a bit from the 4_3 stream.
>
> And on top of that I got diverted by a bug in the session stuff too.
>
> Well as I always say in my volunteer posts - if you don't like the job I am
> doing - cut my pay, if you like what I am doing you can double it - either
> way the result is the same :-)
>
> I will try to get the file descriptors stuff in by early next week.
>
> Dave
>
>
>

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> large patch and probably no one got to check it all out). Then, I
> reposted them (and sent then directly to you, Dave!) a few days ago.

And I got all but the three files merged that are probably causing his
problem too - sigh-

Sorry but I don't commit what I don't understand, and the three streams
files needed some more understanding on my part. In those areas the php5
head differs quite a bit from the 4_3 stream.

And on top of that I got diverted by a bug in the session stuff too.

Well as I always say in my volunteer posts - if you don't like the job I am
doing - cut my pay, if you like what I am doing you can double it - either
way the result is the same :-)

I will try to get the file descriptors stuff in by early next week.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

> Please coordinate with me on streams issues; if some 64bit oses declare
> descriptors as longs rather than ints, then we could have a bigger job
> on our hands (similar to the mess with socket types under win32).

Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is
an int, which is part of the problem because the streams code in 4.3 casts
it wrong.

James sent me a patch that included a cast fix, but I have yet to submit it
(or try too) because I got caught up in trying to follow the code and then
got diverted. I will endevor to finish my look at the patch  and see if Jani
will let me commit it.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

On Fri, 14 Mar 2003, David Hill wrote:
> > Please coordinate with me on streams issues; if some 64bit oses declare
> > descriptors as longs rather than ints, then we could have a bigger job
> > on our hands (similar to the mess with socket types under win32).
>
> Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is
> an int, which is part of the problem because the streams code in 4.3 casts
> it wrong.
>
> James sent me a patch that included a cast fix, but I have yet to submit it
> (or try too) because I got caught up in trying to follow the code and then
> got diverted. I will endevor to finish my look at the patch  and see if Jani
> will let me commit it.

Which part of "please coordinate with me on streams issues" didn't you
get? ;-)

If there are long vs int issues in streams, please let me know where
they are and I will fix it.

Thanks :)

--Wez.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[David Hill]

>
> Which part of "please coordinate with me on streams issues" didn't you
> get? ;-)
>
> If there are long vs int issues in streams, please let me know where
> they are and I will fix it.
>
> Thanks :)

Forgive me if I am a bit dense tonight :-) My 15 yr old son is having a lan
party in the basement with about 9 friends and I am tech support and the
wine I am drinking to help things is not helping matters :-) Oh to be young
again LOL.

I will send you the proposed diffs when I get a moment to prepare them and
let you submit them as you probably are a better sanity check.

Dave


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 64bit PHP on solaris

[James Devenish]

In message <[EMAIL PROTECTED]>
on Fri, Mar 14, 2003 at 05:22:11PM +, Wez Furlong wrote:
> Please coordinate with me on streams issues; if some 64bit oses
> declare descriptors as longs rather than ints, then we could have a
> bigger job on our hands (similar to the mess with socket types under
> win32).

Regardless of any potential disasters with _php_stream_cast, there are
at least a few unsubtle storage-type conflicts. In my case, fds are
stored as ints but PHP casts them to pointers.

In message <[EMAIL PROTECTED]>
on Fri, Mar 14, 2003 at 11:00:50AM -0500, David Hill wrote:
> Sorry but I don't commit what I don't understand, and the three streams
> files needed some more understanding on my part. In those areas the php5
> head differs quite a bit from the 4_3 stream.

Regardless of what you personally understand (and what I personally
understand), my point would be that the problems are simply unfixed
by *anyone*.

Even so, I don't know what would be hard for anyone to understand about
my patches (and no-one has asked me in the past). If you think there
simply too many of them, most of them are probably whitespace
disagreements between what you committed and what the PHP style appears
to be. The basis of all my streams patches is like this (from the old
streams.c):

Index: main/streams.c
===
RCS file: /repository/php4/main/Attic/streams.c,v
retrieving revision 1.125.2.37
diff -u -u -r1.125.2.37 streams.c
--- main/streams.c  6 Mar 2003 20:58:19 -   1.125.2.37
+++ main/streams.c  8 Mar 2003 10:48:16 -
@@ -1532,7 +1532,7 @@
}
if (ret) {
fflush(data->file);
-   *ret = (void*)fd;
+   *(int*)ret = fd;
}
return SUCCESS;
default:

What have I done? Well, someone's taking fd (declared as an 'int', which
may be 32 bits on some systems), casting it a void* (a 64-bit value on
some systems) and then stuffing that into storage space which, although
it might not be obvious, happens to be only 32 bits wide. My patch takes
fd (the 'int') and stuffs it into 'int' storage. Now that's not to say
that the destination IS actually an 'int' but merely that I am keeping
the int at its original width rather than casting it up. It's not a
'perfect solution', but it's not a 'perfect problem', either.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php