Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming Hardening in PHP

dustri.org

Post reply on HN
Print view View original

51–60 of 130 posts

Re: Upcoming Hardening in PHP

#51

Post by ChrisMarshallNY »

phplovesong wrote: post #41
justinclift wrote: post #6

> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain. Big Oof. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

I tend to use PHP for my backend work.

In my experience, it’s actually very fast. That may be partly because of the way I write the code, though, and my backend code isn’t really too massive.

Re: Upcoming Hardening in PHP

#52

Post by 0points »

phplovesong wrote: post #41
justinclift wrote: post #6

> Suggestion to make those parts read-only was rejected as a 0.6% performance impact was deemed too expensive for too little gain. Big Oof. :( :( :(

PHP has always ben slow, its getting slightly faster, but still REALLY, REALLY slow for anything CPU heavy. This is why the ML crowd sticks with Python (numpy) thats incredibly fast. PHP is still lacking, there is no unicode support, and for a web language this is really bad. Also, the way PHP functions, makes modern web (like websockets) use impossible, there is hacks around this but they all kind of suck.

> This is why the ML crowd sticks with Python (numpy) thats incredibly fast.

That is not why.

You stick to python because it's your common denominator. You all picked it up in school.

Python the most popular language around, and one of the slowest.

Re: Upcoming Hardening in PHP

#53

Post by tored »

mklepaczewski wrote: post #47
p4bl0 wrote: post #24

Something I'd really like is for PHP to somehow be stricter on the number of arguments passed to a function. As of now, PHP emits an error if arguments are missing but not if there are too many. A way to bake that in without breaking old code would be to allow function definition to put an explicit stop to the argument list, for example using the void type keyword: function foo (int $a, string $b, void) : bool { ...…

I'm not a fan of the void argument syntax. Wouldn't something like the code below work? We already do it with `strict_types=1`. <?php declare(strict_args=1);

Mark the function with an attribute to allow the old behavior. See link for similar use case.

https://www.php.net/manual/en/class.allowdynamicproperties.p...

Re: Upcoming Hardening in PHP

#54

Post by p4bl0 »

notresidenter wrote: post #43
p4bl0 wrote: post #35

Earlier quoted context omitted.

> the only way you’d ever know is through static analysis Not for builtin PHP functions which already throw errors on arity mismatch. > this would literally break class autoloading in symfony, and even the engine itself, which relies on this feature I don't understand. Could you point to where in the Symfony code it relies on being able to wrongly call a function with more arguments than it expects and will use? For…

You should look at `func_get_args()` usage in the wild. This is sometimes used for (mostly outdated) good-enough reasons and doing this might break it?

I know of func_get_args, but proper variadic functions have been a thing since PHP 5.6 (released more than 10 years ago) using the ... operator. Also, my initial proposal doesn't break existing code :).

Re: Upcoming Hardening in PHP

#55

Post by ChrisMarshallNY »

ipaddr wrote: post #18
that_guy_iain wrote: post #15

Earlier quoted context omitted.

Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version. The last part makes the fact their could be massive security holes like RCE in…

Historically they have been one of the languages that added very few breaking changes and were criticized for that. You can't have it both ways. Going from php 4 to php 8 isn't even that painful and there are twenty years between. It's the one language where what you wrote 20 years ago probably still works today. Upgrading a php application is one of the least expensive and uneventful things you can do. Try upgrading…

There’s a system that I started working on, in 2008, when a lot of hosting outfits were still running PHP 4. It’s still running now, but I think one of the current maintainers rewrote a lot of it with Laravel, recently.

I know that they were still using the old code, just a year or so ago, on PHP 8.

Re: Upcoming Hardening in PHP

#56

Post by ChrisMarshallNY »

esskay wrote: post #38
that_guy_iain wrote: post #15

Earlier quoted context omitted.

Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version. The last part makes the fact their could be massive security holes like RCE in…

> From historically just adding features whenever to know adding hundreds of breaking changes per minor release. Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it. PHP spent a long time running on fumes with little backing. It's now got huge financial backing from Jet…

Doesn’t Facebook still run most of their backend on Hack[0] (compiled PHP subset)?

[0] https://hacklang.org/

Re: Upcoming Hardening in PHP

#57

Post by mklepaczewski »

tored wrote: post #53
mklepaczewski wrote: post #47

Earlier quoted context omitted.

I'm not a fan of the void argument syntax. Wouldn't something like the code below work? We already do it with `strict_types=1`. <?php declare(strict_args=1);

Mark the function with an attribute to allow the old behavior. See link for similar use case. https://www.php.net/manual/en/class.allowdynamicproperties.p...

Yup, that's even better.

Re: Upcoming Hardening in PHP

#59

Post by tored »

that_guy_iain wrote: post #15
mgaunard wrote: post #3

The real question is why does PHP have so many bugs that it's so trivial to exploit?

Honestly, the development of the PHP core has always been rather amateur. From historically just adding features whenever to know adding hundreds of breaking changes per minor release. This results in a terrible codebase and a language where upgrading minor versions is so painful and costly for some firms they end up stuck on old version. The last part makes the fact their could be massive security holes like RCE in…

Since PHP introduced the formal RFC process for changing the language things has become much less cowboy and much more professional.

Typically it is features before that causes problems.

Re: Upcoming Hardening in PHP

#60

Post by p4bl0 »

mklepaczewski wrote: post #57
tored wrote: post #53

Earlier quoted context omitted.

Mark the function with an attribute to allow the old behavior. See link for similar use case. https://www.php.net/manual/en/class.allowdynamicproperties.p...

Yup, that's even better.

That's equivalent to my initial proposal, except that mine adds the information in the type signature of the function rather than in a decorator.
Post reply on HN