[PHP-DEV] [off] PHP: a fractal of bad design

Hi folks,

today I read this post, I think that some points are valid, follow the link for
you guys

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Adir Kuhn
ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
PSMI - Professional Scrum Master I

hi,


On Tue, Apr 10, 2012 at 6:20 PM, Adir Kuhn <[email protected]> wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

Sorry but this list is not a SEO booster. Thanks for your understanding,

PS: This blog brings zero thing new, got many wrong facts and only
repeats what have been said for over a decade about parameters order.
Not sure how one can have so much free time in his hand to write such
useless things.


Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

On Tue, 10 Apr 2012 17:20:41 +0100, Adir Kuhn <[email protected]> wrote:

> Hi folks,
>
> today I read this post, I think that some points are valid, follow the
> link for you guys
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>

This is really long. I stopped reading in full when he complained about
the error-code model.

Is there anything actually susceptible of being actioned upon there or
it's just the usual "PHP is inconsistent" rant -- something we can all
agree on some degree, but which is usually irrelevant given BC concerns?

--
Gustavo Lopes

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

Hi!

> today I read this post, I think that some points are valid, follow the link for
> you guys
>

Could you name a few and explain why you think they are valid and what
you propose to do to fix them? This article is huge and if you want to
start a discussion that makes sense (as opposed to a rant which is, I am
sure, very therapeutic for the author of the post but I'm not sure why
should we care) I think the approach of "read the whole thing and guess
what I meant by 'some points'" is not the best one.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

On Tue, Apr 10, 2012 at 9:38 AM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > today I read this post, I think that some points are valid, follow the
> link for
> > you guys
> >
>
> Could you name a few and explain why you think they are valid and what
> you propose to do to fix them? This article is huge and if you want to
> start a discussion that makes sense (as opposed to a rant which is, I am
> sure, very therapeutic for the author of the post but I'm not sure why
> should we care) I think the approach of "read the whole thing and guess
> what I meant by 'some points'" is not the best one.
>

+1


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Do you know why a full 1/3 of the internet uses PHP? BECAUSE IT WORKS!!
It is easy for newcomers and veterans alike. It's very forgiving when it
comes to typing and other semantics. As far as an error stack goes, PHP
really doesn't *need* once IMHO because the error messages are already
surprisingly precise (with a few notable exceptions lol), typically telling
you not just what the error is but exactly *where* it is, right down to the
line number! Personally, I think that's just fucking awesome.

I started programming at the age of 12 using GW BASIC on my old 286 (I
remember how excited I was when my brother managed to obtain a pirated copy
of QuickBASIC lol). I later "matured" into C/C++. I didn't start using
PHP until I was 19 or 20. It's been my favorite language to work in ever
since. It always amuses me when PERL developers go on their little
soapboxes about how "real" programmers all think PHP is stupid lol.

Granted, PHP has MANY flaws, some of which are accurately mentioned in the
article (though as Pierre pointed out, it doesn't actually raise any new
points; and yes I did read the whole thing, including the comments). There
are some things that PERL and "Ruby with [sic?!] Rails" do better. But
that's why we're here. Instead of trying to use the Internals list to
boost the SEO of your blog, why not actually contribute to make the
language better? Or do you prefer to just be an armchair quarterback?

--Kris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> It always amuses me when PERL developers go on their little
> soapboxes about how "real" programmers all think PHP is stupid
> lol.

It always amuses me PHP people think perl is stupid and vice versa.
Both languages have their use case, sometimes I even use them side by
side in the same project. PHP daemons and forking is not exactly what
I would depend on working reliably.

> Granted, PHP has MANY flaws, some of which are accurately mentioned
> in the article (though as Pierre pointed out, it doesn't actually
> raise any new points; and yes I did read the whole thing, including
> the comments). There are some things that PERL and "Ruby with
> [sic?!] Rails" do better. But that's why we're here.

Exactly. There's a lot to improve and sometimes it can be done with
little to now bc breaks. (And some breaks I would not mind if done
right and for the right reasons).


- --
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+EeBcACgkQCs1dsHJ/X7DtXgCgjnp/QXvpkSo/i5AYamIVhp+s
xS4AoO3vO25gDlvTyziUC0k3GYo19KDE
=Yt9n
-----END PGP SIGNATURE-----

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

Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying "this was fixed in PHP
5.x.y." If it was fixed, why is it on your laundry list still?

On Tue, Apr 10, 2012 at 12:31 PM, Pierre Joye <[email protected]> wrote:
> hi,
>
>
> On Tue, Apr 10, 2012 at 6:20 PM, Adir Kuhn <[email protected]> wrote:
>> Hi folks,
>>
>> today I read this post, I think that some points are valid, follow the link for
>> you guys
>>
>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>
> Sorry but this list is not a SEO booster. Thanks for your understanding,
>
> PS: This blog brings zero thing new, got many wrong facts and only
> repeats what have been said for over a decade about parameters order.
> Not sure how one can have so much free time in his hand to write such
> useless things.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

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

Hi!

> Scroll down a bit; he gets into valid points about the == operator,
> for instance. It's not a useless post. He does cite too many things
> that he has to follow up himself by saying "this was fixed in PHP
> 5.x.y." If it was fixed, why is it on your laundry list still?

What exactly valid points? == is a converting operator, === is a strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's "useless". Well, a lot of things would be
useless if you don't want to know how to use them.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang <[email protected]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > It always amuses me when PERL developers go on their little
> > soapboxes about how "real" programmers all think PHP is stupid
> > lol.
>
> It always amuses me PHP people think perl is stupid and vice versa.
> Both languages have their use case, sometimes I even use them side by
> side in the same project. PHP daemons and forking is not exactly what
> I would depend on working reliably.
>

Umm at what point did I say PERL is "stupid?" PERL is like the duct-tape
of scripting languages; it can be used for just about anything, though
there's almost always a more specialized solution. It serves a purpose.

But that being said, PERL has tons of flaws and other issues all its own.
That's why it amuses me whenever I see a PERL person get on a soapbox about
PHP. Hypocrisy is funny.


>
> > Granted, PHP has MANY flaws, some of which are accurately mentioned
> > in the article (though as Pierre pointed out, it doesn't actually
> > raise any new points; and yes I did read the whole thing, including
> > the comments). There are some things that PERL and "Ruby with
> > [sic?!] Rails" do better. But that's why we're here.
>
> Exactly. There's a lot to improve and sometimes it can be done with
> little to now bc breaks. (And some breaks I would not mind if done
> right and for the right reasons).
>
>
> - --
> Ralf Lang
> Linux Consultant / Developer
> Tel.: +49-170-6381563
> Mail: lang@b1-systems.de
>
> B1 Systems GmbH
> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+EeBcACgkQCs1dsHJ/X7DtXgCgjnp/QXvpkSo/i5AYamIVhp+s
> xS4AoO3vO25gDlvTyziUC0k3GYo19KDE
> =Yt9n
> -----END PGP SIGNATURE-----
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Kris Craig wrote:
> PERL is like the duct-tape
> of scripting languages; it can be used for just about anything, though
> there's almost always a more specialized solution. It serves a purpose.

Perhaps not the most ideal of comparisons ... The last thing you use 'duct-tape'
for is sealing ducts ... you need to use the right tape for THAT job :)

My own problem is convincing customers that the systems they have been using
reliably for 10 years NEED to change. PHP does a good job for all of my
customers and they see no reason to have to change things. What they have been
doing for years has not changed in years so why change.

Once on is used to the warts, 'fixing them' is an even more annoyance, so please
can we stop complaining about things that are broken ... and leave those of us
who are more than happy with what we have to just carry on 'doing things all
wrong' :)

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

hi Tom,


On Tue, Apr 10, 2012 at 8:18 PM, Tom Boutell <[email protected]> wrote:
> Scroll down a bit; he gets into valid points about the == operator,
> for instance. It's not a useless post. He does cite too many things
> that he has to follow up himself by saying "this was fixed in PHP
> 5.x.y." If it was fixed, why is it on your laundry list still?

Nothing in his post is valid.

The == vs === is a PHP 101 problem, if one does not know the
difference, then there is no hope yet to even try to figure other
possible good points.

Everything else are the same stuff everyone has once complained about
and did not want to change because of BC reasons.

Nothing new, nothing to see, simple SEO oriented rant.

Cheers,
--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

On Tue, Apr 10, 2012 at 9:20 AM, Adir Kuhn <[email protected]> wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys

"Ideally, don’t tell me anything!"

That's doable. No point trying to talk to a ranter.

-Ronabop

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

Hi,

It was fun to read. I understand he just don't like PHP.
His article may be good for novice users to understand how PHP will behave.

I guess he learned PHP a lot, but he lists framework feature as
missing. I wander why. He seems to like Python, but Python's multibyte
support was awful until recent.

Anyway,
http://www.php.net/manual/en/security.database.sql-injection.php
I've never read this page. This page must be improved...

I haven't read all, but there may be other places that may help.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

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

Stopped reading after encountered "E_ACTUALLY_ALL", "for ($foo as &$bar)" -
these things required me to google or to refer to docs to ensure I was not
missing something. And, yes, I should have stopped after the words "don’t
tell me anything!". People who refuse to listen do not deserve to be heard.

2012/4/11 Yasuo Ohgaki <[email protected]>

> Hi,
>
> It was fun to read. I understand he just don't like PHP.
> His article may be good for novice users to understand how PHP will behave.
>
> I guess he learned PHP a lot, but he lists framework feature as
> missing. I wander why. He seems to like Python, but Python's multibyte
> support was awful until recent.
>
> Anyway,
> http://www.php.net/manual/en/security.database.sql-injection.php
> I've never read this page. This page must be improved...
>
> I haven't read all, but there may be other places that may help.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Yasuo Ohgaki wrote:
> Anyway,
> http://www.php.net/manual/en/security.database.sql-injection.php
> I've never read this page. This page must be improved...

That is almost archaic it's self ...
It should be replaced with a pointer to using parameters ( no we do not need
'prepared statements', just parameters ). One of the first things I implement on
any code that I'm porting. Does away with any agro over escaping strings and is
totally save 'injection' wise.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

I do agree with a lot of what was being said. But what can you do?
These are mostly quirks of the language. You learn to live with them.
I don't make excuses for it. It is what it is.

The only thing that infuriates me is the ternary operator being left
associative. I want that fixed - screw bc on that one! I have been
programming for 10 years and that one still confuses me! Most people
just add parentheses to "fix" the problem. I wish someone would write
an RFC to change this to right associative like every other language!
*hint hint*

Luke Scott

On Apr 10, 2012, at 9:21 AM, Adir Kuhn <[email protected]> wrote:

> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>
> Adir Kuhn
> ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035
> PSMI - Professional Scrum Master I

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

Hey Lester,

On 4/11/12 3:29 AM, Lester Caine wrote:

> That is almost archaic it's self ...
> It should be replaced with a pointer to using parameters ( no we do not
> need 'prepared statements', just parameters ). One of the first things I
> implement on any code that I'm porting. Does away with any agro over
> escaping strings and is totally save 'injection' wise.

While I generally agree, 'just parameters' does have it's limitations.
Sometimes there are special character sequences that can be exploited to
escape out of a quoted value in a SQL string.

Offhand, this comes to mind about MySQL:
http://bugs.mysql.com/bug.php?id=8378

-ralph



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

Ralph Schindler wrote:
> Hey Lester,
>
>> That is almost archaic it's self ...
>> It should be replaced with a pointer to using parameters ( no we do not
>> need 'prepared statements', just parameters ). One of the first things I
>> implement on any code that I'm porting. Does away with any agro over
>> escaping strings and is totally save 'injection' wise.
>
> While I generally agree, 'just parameters' does have it's limitations. Sometimes
> there are special character sequences that can be exploited to escape out of a
> quoted value in a SQL string.
>
> Offhand, this comes to mind about MySQL:
> http://bugs.mysql.com/bug.php?id=8378

Well if you must use a simple database ;)

I've never used MySQL simply because it has yet to get to the same standard as
Firebird ... But I'm talking about passing parameters direct to '?' entries in
the SQL - something which if it CAN be broken then the database is also broken?
The database handles the 'data' going into a single field at a time.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

Lester,

Even with PDO and older versions of MySQL, you could inject into
prepared statements quite easily (assuming charset settings):

$var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';

$pdo = new PDO('mysql:...');
$pdo->query('SET NAMES GBK');
$stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
$stmt->bindParam(1, $var);
$stmt->execute();

Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
first, that will successfully inject into the query thanks to how PDO
emulates prepares.

A problem that true prepared statements (MySQLi and if PDO has emulate
prepares off) is immune to...

Anthony

On Wed, Apr 11, 2012 at 12:06 PM, Lester Caine <[email protected]> wrote:
> Ralph Schindler wrote:
>>
>> Hey Lester,
>>
>>
>>> That is almost archaic it's self ...
>>> It should be replaced with a pointer to using parameters ( no we do not
>>> need 'prepared statements', just parameters ). One of the first things I
>>> implement on any code that I'm porting. Does away with any agro over
>>> escaping strings and is totally save 'injection' wise.
>>
>>
>> While I generally agree, 'just parameters' does have it's limitations.
>> Sometimes
>> there are special character sequences that can be exploited to escape out
>> of a
>> quoted value in a SQL string.
>>
>> Offhand, this comes to mind about MySQL:
>> http://bugs.mysql.com/bug.php?id=8378
>
>
> Well if you must use a simple database ;)
>
> I've never used MySQL simply because it has yet to get to the same standard
> as Firebird ... But I'm talking about passing parameters direct to '?'
> entries in the SQL - something which if it CAN be broken then the database
> is also broken? The database handles the 'data' going into a single field at
> a time.
>
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk//
> Firebird - http://www.firebirdsql.org/index.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Anthony Ferrara wrote:
> Even with PDO and older versions of MySQL, you could inject into
> prepared statements quite easily (assuming charset settings):
>
> $var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
>
> $pdo = new PDO('mysql:...');
> $pdo->query('SET NAMES GBK');
> $stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
> $stmt->bindParam(1, $var);
> $stmt->execute();
>
> Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
> first, that will successfully inject into the query thanks to how PDO
> emulates prepares.
>
> A problem that true prepared statements (MySQLi and if PDO has emulate
> prepares off) is immune to...

Try doing that with a real database ;)

Firebird is not susceptible to this sort of problem. And I have still to find
any use for PDO in real systems. It's just another layer that gets in the way of
processing data securely. Emulating things half cocked is simply another
security hole anyway.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

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

On Wed, 2012-04-11 at 19:44 +0100, Lester Caine wrote:
> Anthony Ferrara wrote:
> > Even with PDO and older versions of MySQL, you could inject into
> > prepared statements quite easily (assuming charset settings):
> >
> > $var = '1' . chr(0xbf) . chr(0x27) . ' OR 1=1';
> >
> > $pdo = new PDO('mysql:...');
> > $pdo->query('SET NAMES GBK');
> > $stmt = $pdo->prepare('SELECT * FROM foo WHERE 2 = ?');
> > $stmt->bindParam(1, $var);
> > $stmt->execute();
> >
> > Without setting $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, 0)
> > first, that will successfully inject into the query thanks to how PDO
> > emulates prepares.
> >
> > A problem that true prepared statements (MySQLi and if PDO has emulate
> > prepares off) is immune to...
>
> Try doing that with a real database ;)

If PDO decided to use emulation by default (which has benefits like
fewer roundtrips etc.) it's not necessarily the issue from the database.

And that this doesn't work is obvious with emulation - PDO doesn't parse
the SQL and has no understanding of "SET NAMES", neither does the MySQL
client lib used. The proper way to set the encoding is by using the
DSN's charset option.

johannes



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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 10.04.2012 20:28, schrieb Kris Craig:
> On Tue, Apr 10, 2012 at 11:12 AM, Ralf Lang <[email protected]>
> wrote:
>
>>>> It always amuses me when PERL developers go on their little
>>>> soapboxes about how "real" programmers all think PHP is
>>>> stupid lol.
>
> It always amuses me PHP people think perl is stupid and vice
> versa. Both languages have their use case, sometimes I even use
> them side by side in the same project. PHP daemons and forking is
> not exactly what I would depend on working reliably.
>
>
>> Umm at what point did I say PERL is "stupid?" PERL is like the
>> duct-tape of scripting languages; it can be used for just about
>> anything, though there's almost always a more specialized
>> solution. It serves a purpose.

I did not mean you personally told anything about perl. Of course perl
serves a purpose. That's why it's still around.



- --
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+F8x8ACgkQCs1dsHJ/X7AjMACfcGvNM7Nz6FBQ2yZDNtiw9L7M
AFsAoMjTbEtdQcicPuayb8GAtOTi5F0I
=wLGk
-----END PGP SIGNATURE-----

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

On 04/10/2012 06:20 PM, Adir Kuhn wrote:
> Hi folks,
>
> today I read this post, I think that some points are valid, follow the link for
> you guys

as stuff like this comes up again and again (although not in as epic
lenght as this one) i've been thinking whether it might make sense to
have some

"PHP Gotchas, how they came to be, and why we can't simply fix them"

FAQ section in the manual or wiki?

If nothing else it would at least help with dealing with this kind
of rant (nothing new here, move along, your concerns were already
covered in ### in great detail), but also might help that would
indeed want to understand why some things are as they are.

I'd rather proactively own this kind of discussions than just
jump into them whenever they arise elsewhere ...

--
hartmut

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

On 04/11/2012 05:19 PM, Luke Scott wrote:

> The only thing that infuriates me is the ternary operator being left
> associative. I want that fixed - screw bc on that one! I have been
> programming for 10 years and that one still confuses me! Most people
> just add parentheses to "fix" the problem. I wish someone would write
> an RFC to change this to right associative like every other language!
> *hint hint*

i actually never noticed this until now as i keep it as a best practice
to never nest ternaries anyway, in any language. To me it's at least as
much a sign for a desseased mind as using multiple exclamation marks
!!!11eleven ;)

The problem i see though is that in code that really relies on this it
may become a real nightmare to track down what goes wrong if evaluation
order is changed if you're not aware of that change having happened.

An E_DEPRECATED may help here, but will also produce a lot of false
positives for those using parentheses? Or can we add enough parser
magic to only throw warnings for the unsafe uses? ...

--
hartmut

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

On Apr 18, 2012, at 1:34 AM, Hartmut Holzgraefe wrote:

> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>> Hi folks,
>>
>> today I read this post, I think that some points are valid, follow the link for
>> you guys
>
> as stuff like this comes up again and again (although not in as epic
> lenght as this one) i've been thinking whether it might make sense to
> have some
>
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
>
> FAQ section in the manual or wiki?
>
> If nothing else it would at least help with dealing with this kind
> of rant (nothing new here, move along, your concerns were already
> covered in ### in great detail), but also might help that would
> indeed want to understand why some things are as they are.
>
> I'd rather proactively own this kind of discussions than just
> jump into them whenever they arise elsewhere …

Hello Hartmut,

Agreed, and I think it belongs in the manual. An example (not being
proposed as such, but is a rough idea):

Why are function naming schemes seemingly random?

PHP glues many different API's together, and sometimes this
gets messy. PHP leans towards the C variant which is why the
likes of strlen() vs str_replace() exists, and …

As opposed to our current approach, which is via mailing lists and
typically "RTFM." or "BC. Read archives." or the like. Ack!

And also include possible solutions/recommendations like this PHP FAQ
entry about haystack,needle ordering, which includes the following
text:

A simple rule of thumb is as follows: Array function parameters
are ordered as "needle, haystack" whereas String functions are the
opposite, so "haystack, needle".

And thankfully there are already a lot of sites to steal the questions
from, and often answers live within their user comments. :)

Regards,
Philip


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

On Tue, April 10, 2012 1:27 pm, Stas Malyshev wrote:
> Hi!
>
>> Scroll down a bit; he gets into valid points about the == operator,
>> for instance. It's not a useless post. He does cite too many things
>> that he has to follow up himself by saying "this was fixed in PHP
>> 5.x.y." If it was fixed, why is it on your laundry list still?
>
> What exactly valid points? == is a converting operator, === is a
> strict
> operator. OK, in his favorite language it is not. Where exactly the
> valid point is? Author goes at great lengths to refuse to make even a
> slight mental effort to understand how it works (really, it's not that
> hard) and then complains it's "useless". Well, a lot of things would
> be
> useless if you don't want to know how to use them.

He has a few valid points in the part I read before I got bored...

$a = "123ABF453..."; //a password
$b = "123DFEABC..."; //another one
if ($a == $b){
//you're in.
}

Yes, one should have validated the input...

But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's "safe"...

I'll bet I have some of these in my (recent) code, for that matter.

On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



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

On Sun, May 6, 2012 at 12:17 AM, Richard Lynch <[email protected]> wrote:
>> What exactly valid points? == is a converting operator, === is a
>> strict
>> operator. OK, in his favorite language it is not. Where exactly the
>> valid point is? Author goes at great lengths to refuse to make even a
>> slight mental effort to understand how it works (really, it's not that
>> hard) and then complains it's "useless". Well, a lot of things would
>> be
>> useless if you don't want to know how to use them.
>
> He has a few valid points in the part I read before I got bored...
>
> $a = "123ABF453..."; //a password
> $b = "123DFEABC..."; //another one
> if ($a == $b){
>  //you're in.
> }
>
> Yes, one should have validated the input...
>
> But you don't have to be THAT naive to think that the hashed value of
> an SQL injection attack just isn't going to work, so it's "safe"...
>
> I'll bet I have some of these in my (recent) code, for that matter.
>
> On the other hand, if you accept type juggling, you have to expect the
> other cases he has for == being a bit strange.

Validated or not, why would type juggling even come into the picture
if both variables are of the same type?

123 == "123abc" // sure, why not
"61529519452809720693702583126814" ==
"61529519452809720000000000000000" // WAT?!

In the above, only the first ~50% of an md5 hash has to be correct.
This gets even worse for SHA256 hashes.

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

Hello internals,

I should voice my opinion that such things like comparing two strings
starting with numbers and that they resolve to actual integer/float for
comparation is bad, really bad. That just defies the logic and yealds
absolutly unexpected results. I pride myself that i know the juggling rules
well, but I'm shocked by this to say the least...
In my opinion this should change no matter the BC breaks it will create,
this one affects security big time. It's good I actually hash my passwords
in the MySQL and not on the PHP side, but I have seen hash comparations
with == all the time. And now that this has been discussed in detail I
expect this to be used as an attack method grow wide.
07.05.2012 5:32 пользователь "Tjerk Anne Meesters" <[email protected]>
написал:

> On Sun, May 6, 2012 at 12:17 AM, Richard Lynch <[email protected]> wrote:
> >> What exactly valid points? == is a converting operator, === is a
> >> strict
> >> operator. OK, in his favorite language it is not. Where exactly the
> >> valid point is? Author goes at great lengths to refuse to make even a
> >> slight mental effort to understand how it works (really, it's not that
> >> hard) and then complains it's "useless". Well, a lot of things would
> >> be
> >> useless if you don't want to know how to use them.
> >
> > He has a few valid points in the part I read before I got bored...
> >
> > $a = "123ABF453..."; //a password
> > $b = "123DFEABC..."; //another one
> > if ($a == $b){
> > //you're in.
> > }
> >
> > Yes, one should have validated the input...
> >
> > But you don't have to be THAT naive to think that the hashed value of
> > an SQL injection attack just isn't going to work, so it's "safe"...
> >
> > I'll bet I have some of these in my (recent) code, for that matter.
> >
> > On the other hand, if you accept type juggling, you have to expect the
> > other cases he has for == being a bit strange.
>
> Validated or not, why would type juggling even come into the picture
> if both variables are of the same type?
>
> 123 == "123abc" // sure, why not
> "61529519452809720693702583126814" ==
> "61529519452809720000000000000000" // WAT?!
>
> In the above, only the first ~50% of an md5 hash has to be correct.
> This gets even worse for SHA256 hashes.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Mon, May 7, 2012 at 12:28 AM, Arvids Godjuks <[email protected]>wrote:

> Hello internals,
>
> I should voice my opinion that such things like comparing two strings
> starting with numbers and that they resolve to actual integer/float for
> comparation is bad, really bad. That just defies the logic and yealds
> absolutly unexpected results. I pride myself that i know the juggling rules
> well, but I'm shocked by this to say the least...
> In my opinion this should change no matter the BC breaks it will create,
> this one affects security big time. It's good I actually hash my passwords
> in the MySQL and not on the PHP side, but I have seen hash comparations
> with == all the time. And now that this has been discussed in detail I
> expect this to be used as an attack method grow wide.
> 07.05.2012 5:32 пользователь "Tjerk Anne Meesters" <[email protected]>
> написал:


Forgive me if I'm missing something, but why are people using == for
security-sensitive string comparisons (like hashed passwords) in the first
place?! If you needs something that's safe, isn't that what strcmp() and
strcasecmp() are for? For my part, I pretty much never use == on string
comparison, though admittedly that's probably just a matter of having
having come from a C background before PHP.

That being said, I agree that this *definitely* should be fixed if the
examples cited are indeed accurate (I've been working with PHP for over 10
years and I was never aware of this bizarre behavior, either). I don't
know the history of this, but I at least would consider it to be a bug. A
rather large one, in fact; though I think some of the fears expressed are a
bit hyperbolic. And if you're fixing a serious bug or security
vulnerability, as a general rule of thumb, this automatically supercedes
any concerns regarding BC breakage IMHO. But if that really is a lingering
concern, I'd suggest targetting the fix for PHP 6, since people would (or
at least should) expect that some PHP 5 code may behave differently in PHP
6 anyway given that it's a major release

--Kris

On Mon, 07 May 2012 10:31:00 +0200, Kris Craig <[email protected]>
wrote:

> That being said, I agree that this *definitely* should be fixed if the
> examples cited are indeed accurate (I've been working with PHP for over
> 10 years and I was never aware of this bizarre behavior, either). I
> don't
> know the history of this, but I at least would consider it to be a bug.
> A rather large one, in fact; though I think some of the fears expressed
> are a bit hyperbolic. And if you're fixing a serious bug or security
> vulnerability, as a general rule of thumb, this automatically supercedes
> any concerns regarding BC breakage IMHO.

This has already been discussed in its own thread, see
http://comments.gmane.org/gmane.comp.php.devel/72790 ; see also
https://bugs.php.net/bug.php?id=54547

Doing away entirely with this behavior (e.g. making " 2" == "2" compare
false) would be a rather large BC break, that discussion is restricted to
whether integers in strings should be treated differently from integer
literals for comparison purposes when their range is exceeded. I wrote a
patch for that, and, while not really caring one way or the other, I'm not
convinced it's necessary and I some have consistency concerns (though
float overflows already get a similar treatment).

--
Gustavo Lopes

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