Unexpectedly correct program behavior

Question

PHP

From time to time I come across a situation where this or that system should not work, but for some reason it works. I do not like such situations for two reasons - it is difficult to catch, and colleagues look askance ... after all, it works, what do you need.

And how do you feel about such "artificial intelligence"?

On the one hand, it seems to work. And in 90% of cases, it turns out that I once provided for something a long time ago that allowed it to work this way. On the other hand, if it is not clear why it works, then it may not work correctly, and therefore be vulnerable.

Example - today I showed a colleague a test of one library that I am currently writing.

And I noticed that I made a typo there. Instead:

$data = $zarplata->read('money< ? ',100);

wrote

$data = $zarplata->read('money<',100);

those. missed the placeholder.

It turned out that the code worked correctly, and according to the test results, everything was ok.

The debriefing showed that it worked due to the fact that:

list($str_start,$str_end) = explode('#',$where,2);

quietly returns $where as the start of the string, and an empty string as the end.

But there is one thing - this is worked out in the code for processing the placeholder #, which means it is escaped and it is drawn up a little differently. The result is a ready-made sql injection.

With the right design, in fact, it often happens that it works, and you don’t understand why, and this is normal ... but with the wrong one, it can be like this ...

Tell me, am I a paranoid who was accidentally rewarded for my paranoia, or is that right? :

Answer 1

Of course, it needs to be done. As long as the programmers have it, it's cheap to fix. If it breaks under load, it will be very expensive to repair, any QA will tell you that.
It’s much worse when a bug comes from QA, and after the trial, it turns out that it couldn’t work because of this bug for a very long time, but it worked somehow ...

Answer 2

This is what UNITS testing is for, it would reveal the shortcomings of where parsing. And in an osprey, indeed, errors can overlap and give the correct result.

Answer 3

"If you don't know why it works, it probably doesn't work." (S.McConnell, Quote from Perfect Code)
> With proper design, it actually often happens that it works, and you don’t understand why, and this is normal ...
And this is not normal and indicates that something is going wrong so. Now 1 person does not understand how it works, tomorrow - half of the team - in a year - no one knows. What is the direct cause of the increase in the number of defects.

Answer 4

I do not believe in miracles and surprises.
But I believe that the stricter and more different checks to enter, the more errors will pop up. To do this:
1) set error_reporting to -1 (show absolutely all errors, including all sorts of deprecated and strict standards)
2) Sometimes I make code that converts any slightest error into an exception that throws the entire program (in non-PHP languages ​​this is often the default and it is, and it is correct)
3) I specify type hints - if an array or an object of a certain class should come to the function, then I write so
4) I put assert () in bulk. If the array passed to the function must not be empty, and another variable cannot be negative, I check this
5) I don't use @ and I don't fix errors until I understand the reason (since the real error may be in the calling code)
6) In things that accept placeholders, I always check that the number of placeholders and the transmitted data match
7 ) I regret that PHP does not have (or does it already have?) type hints for scalar types
> With proper design, in fact, it often happens that it works, and you do not understand why, and this is normal ...
No, it doesn't happen. You are just bad at code or language features.

Answer 5

Recently I sawed out the old code from the program, where instead of checking for a type there was a cast to type. The code worked for many years on many services and no one noticed. And it could one day go sideways. So yes, you need to immediately search and understand.

Answer 6

Well, yes, since we’ve moved away from the “unexpectedly CORRECT” topic, towards just errors, here’s another example:
in 2006, when I already started writing under php5, but still so that php4 worked ...
I wrote the authorization library.
And doubts tormented me ... but I never figured out why I shouldn't use $_REQUEST instead of $_GET + $_COOKIE.
Did not invent. Wrote.
Now the library is dead. Why? It turns out that request_order appeared in 5.3.
====
This is where I acknowledge the violation of the most important rule of development: “Listen to your ass. If she says don't do it, don't do it." Everything else is general terms. :)