4 ms·

Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually

by snorkel 14y ago

Headline of this post is totally false and this is not even a bug in PHP, it's clearly a bug in the poster's code, so Rasmus response is right. If you actually try doing this in PHP you get this: print number_format("",0); Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1 So the poster willfully ignored the warning. You can fix this simply by casting the first arg as a numeric type: print number_format((int)"",0); 0 Please, if you're this bad at programming and you willfully ignore warnings, don't file bugs, and please do not take a programming job at some place that does important things like air traffic control, banking, or life support systems.

DHowett 14y ago
The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.
- xd 14y ago
  The quote was tongue in cheek.
psaintla 14y ago
I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it) You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.
- wpietri 14y ago
  I don't have a strong opinion either way, but I don't think #1 is a given. You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle http://en.wikipedia.org/wiki/Robustness_principle My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.
  - zbuc 14y ago
    If they were going to take that approach, it should have returned 0 then. I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input. On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
  - psaintla 14y ago
    I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.
- wvenable 14y ago
cldrope 14y ago
This stuff happened over 2 years ago, and what he was referring to was an ANTICIPATED change sir. Not one he'd run into at the time, since it had yet to be changed to something random and unexpected.
- batista 14y ago
  Relying on a brain damaged non documented edge case was unanticipated, not the change --which had also been in beta before release. What kind of programmer passes "" and null on a function such as this and expects ....zero in return? And what kind of programmer does it --as he admits-- "all around the place"? If you give right to this guy, that's a very very short and accurate interview question --no hire.
  - cldrope 14y ago
    You mistake my use of anticipated. I agree with you, I meant the change was anticipated as in "It was expected to happen". It was in the cards to happen eventually, whether it was intelligent or not. Returning null in the math library at all just seems counter-intuitive.

by snorkel 14y ago

DHowett 14y ago

The headline of this post is such because it is quoting a PHP developer on a point made in a later comment on the report.

xd 14y ago
The quote was tongue in cheek.

psaintla 14y ago

I think there are two bigger issues: 1.) Things like this should not be warnings in the first place. There should be more strict handling of invalid input so they result in actual exceptions being thrown instead of output that can be exploited in incorrect/undocumented ways. 2.) The php.net documentation for number_format doesn't even state that NULL is a possible output value. And I can't find anything in the changelogs stating when this change was made (admittedly I glanced quickly so I may have missed it) You state that it is a bug in PHP, but I respectfully disagree. This is a bug in the varied way in which PHP returns output based on invalid input. Some functions return 0, some functions return NULL, some functions return FALSE and it seems as if it is all done arbitrarily. This really should end, invalid input should result in standard exceptions being thrown so they can be handled.

wpietri 14y ago
I don't have a strong opinion either way, but I don't think #1 is a given. You describe one reasonable approach to building things: bad shit should blow up quickly, forcing fixes. But another reasonable way is working to make sure something reasonable happens. E.g., Postel's Robustness Principle: http://en.wikipedia.org/wiki/Robustness_principle http://en.wikipedia.org/wiki/Robustness_principle My understanding is that PHP started out as a noob-friendly page scripting language. For that kind of system, do-what-I-mean coding is reasonable. You're not trying to force amateurs to be pros; you're just trying to help them get something up and working. But maybe the PHP audience has shifted enough that the break-early-break-often approach is the right one these days.
- zbuc 14y ago
  If they were going to take that approach, it should have returned 0 then. I think of this as "garbage in, garbage out". The function will return a numeric value -- if you give it proper input. On two occasions I have been asked,—"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
- psaintla 14y ago
  I'm perfectly fine with the robustness principle being applied, but it seems as if it gives people who write poorly thought out projects a convenient excuse for bad design decisions. I've been using PHP since the early 4.x days, so I've seen the project change over the years and I can honestly say I don't think the robustness principle was ever consciously applied across the project, it just ended up that way. If it was a conscious decision then there would be at a very minimum a standard output for invalid input across all functions. Instead, every function returns something different (FALSE, 0, '', '0', NULL). Sometimes the output for invalid data is documented, sometimes it isn't, sometimes it changes without any notice or modification of the documentation. This doesn't seem like a design choice to me.
wvenable 14y ago

cldrope 14y ago

This stuff happened over 2 years ago, and what he was referring to was an ANTICIPATED change sir. Not one he'd run into at the time, since it had yet to be changed to something random and unexpected.

batista 14y ago
Relying on a brain damaged non documented edge case was unanticipated, not the change --which had also been in beta before release. What kind of programmer passes "" and null on a function such as this and expects ....zero in return? And what kind of programmer does it --as he admits-- "all around the place"? If you give right to this guy, that's a very very short and accurate interview question --no hire.
- cldrope 14y ago
  You mistake my use of anticipated. I agree with you, I meant the change was anticipated as in "It was expected to happen". It was in the cards to happen eventually, whether it was intelligent or not. Returning null in the math library at all just seems counter-intuitive.