| |||||||||||||
PHP: a fractal of bad design (fuzzy notepad)PHP: a fractal of bad design (fuzzy notepad)Posted Apr 17, 2012 19:21 UTC (Tue) by nix (subscriber, #2304)Parent article: PHP: a fractal of bad design (fuzzy notepad) It's an impressive condemnation of the mass of horrible misdesign which is PHP, but I was most impressed by this evidence of the grotesqueness of the internals. Because when trying to avoid integer-overflow bugs, the right solution to detect an input that will wrap at INT_MAX is to compute the size of your memory regions using floating point! (Sure, malloc() still takes a size_t, but I'm sure it'll be able to allocate a floating-point number of bits anytime soon. Just wait.) (In their defence, they did fix this once they were embarrassed about it in public... but nobody writing code for public consumption should commit horrors like that. Nobody.)
(Log in to post comments)
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 17, 2012 20:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Gah.
Can we ask INTERCAL maintainers to give PHP developers a hand? They'll fit right in!
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 18, 2012 9:30 UTC (Wed) by alankila (subscriber, #47141) [Link]
And it was a single-precision floating point, if that above is to be believed. Meaning that once allocation grew large enough, somewhere above 16M, there was a round-off error because the lowest bits aren't accurate after integer conversion.
Impressive and truly sad.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 18, 2012 18:09 UTC (Wed) by nix (subscriber, #2304) [Link]
They could have compensated for this by adding an appropriate amount to the final value (wasting a bit of memory), but nooo... so the thing is as likely to error on the low side as on the high side, and they actually managed to introduce a security hole while trying to fix another one. A security hole that I'm fairly sure nobody else has ever introduced (how many floating-point rounding memory allocation bugs can there be in the world?)
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 18, 2012 18:26 UTC (Wed) by juliank (subscriber, #45896) [Link]
I also count byte sizes in floating point to avoid overflows, but certainly not for memory allocations. No problem for me, as my code does not have to be very fast when calculating things. And because I convert to floating point anyway, as I want to display human-readable sizes with %.3f digits.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 18, 2012 23:34 UTC (Wed) by cmccabe (guest, #60281) [Link]
I doubt that using floats rather than 64-bit integers is saving you any typing.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 19, 2012 8:15 UTC (Thu) by juliank (subscriber, #45896) [Link]
It doesn't when counting, but since I have to convert to double later on anyway, I can just count in double as well.
I could perhaps rewrite the human-readable size formatting to use integers (i.e. print B,KiB,MiB,GiB, TiB), but if I want precision after the period, things will start to get more complicated. And I usually want that precision.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 18, 2012 20:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] The other WTF in that bit of code is that sizeof(char) is by definition 1.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 19, 2012 11:20 UTC (Thu) by rev (guest, #15082) [Link]
Well, that, in my not so humble opinion, they did right.
As a general rule if Y has knowledge about X, and one needs attribute a of X, one needs to query Y for X.a: SPOD. Here, Y=the compiler, X=char and a=sizeof(). There is really no point in relying on sizeof(char) equaling 1. Demonstrating one's macho-ness knowing all this little details about the language to oneself and ones peers? Optimization? Any decent compiler will optimize sizeof(char) away. Saves typing? Hardwiring sizeof(char)==1 violates the SPOD principle. In general, relying on this fact implicitly is even worse: it reduces the maintainability of code. Sooner or later the char in my function is going to be changed. Say to w_char_t. 'malloc((size_t) num)' is likely to be overlooked by me or, somewhat less likely, by my peers, leading to spurious problems. 'malloc(num * sizeof(char))' is likely to be caught on the first pass. Thus, using sizeof(char) makes my code more maintainable.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 19, 2012 14:39 UTC (Thu) by nye (guest, #51576) [Link]
I think that can be summed up as 'avoid magic constants'.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 20, 2012 15:34 UTC (Fri) by rev (guest, #15082) [Link]
Nearly.
Defining a constant for sizeof(char) still leaves us with a SPOD violation: AMC: yes, SPOD: no.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 20, 2012 23:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
What do SPOD and AMC stand for here?
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 0:05 UTC (Sat) by neilbrown (subscriber, #359) [Link]
AMC is "Avoid Magic Constants".
I'm guessing SPOD is "Single Point of Departure".
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 13:49 UTC (Sat) by rev (guest, #15082) [Link]
Single Point Of Definition.
Sorry, I thought the meanings of the acronyms where obvious from the context.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 18:26 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
I had just never come across them before (AMC is strongly tied to the car manufacturer in my mind and SPOD is new).
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 20, 2012 17:26 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
If you did
char *str = malloc (LEN * sizeof *str);
You would not need to change anything if you changed the type of str in the future. Explicitly writing a type, is a maintenance hassle, and writing sizeof(char) is pointless. So doing both is doubly bad, and suggests that the
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 13:56 UTC (Sat) by rev (guest, #15082) [Link]
Yep. That would be even better idiom.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 14:19 UTC (Sat) by rev (guest, #15082) [Link]
A few side notes. Somewhat tongue in cheek, somewhat provocative, and on the other hand, quite serious.
There's only one programming language that's worse than PHP, and that is C. Make that two languages worse than PHP: Perl and C.
Whenever there's a need in a programming language community to take pride in knowing every quirk and detail of a language, as your remark alludes to, the merits of said language are up for debate.
Whenever programmers feel the urge to impress their peers with their knowledge of a programming language, the quality of these programmers is up for debate.
PHP: a fractal of bad design (fuzzy notepad) Posted Apr 21, 2012 16:38 UTC (Sat) by apoelstra (subscriber, #75205) [Link]
The use of the 'sizeof' operator is hardly a detail or quirk of the language -- it is absolutely crucial to any C program that uses dynamically allocated memory.
PHP: a fractal of bad design (fuzzy notepad) Posted May 7, 2012 15:04 UTC (Mon) by rev (guest, #15082) [Link]
Agreed. One of the reasons C should be avoided like the plague.
PHP: a fractal of bad design (fuzzy notepad) Posted May 8, 2012 8:49 UTC (Tue) by nix (subscriber, #2304) [Link]
It's when you find yourself using addition, subtraction, or (size_t)pow() on the result of sizeof() that you really know you're playing with the big boys.
(I've done the first two, but so far have restrained myself from the insanity required for the third, preferring to multiply by hand. How plebeian.)
|
|||||||||||||