INI directives are evil!
April 28, 2016 —Cet article est aussi disponible en français.
A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optionnal1, depending on an INI configuration directive – the idea being each user could then enable it or not.
Still, the idea of directives that could change, sometimes deeply, the behavior of a programming langague… It scares me!
For a moment, let’s think about a language2 developped to facilitate creating HTML forms and dealing with their data.
To help beginners who know nothing about security, and as using MySQL to store data is what people do, this language’s developpers set up an option that, once enabled, automatically causes an \ to be added in front of all ' quotes passed as input3 (GET/POST/…).
Of course, some sysadmins immediately enable this directive, as it considerably improves security4 by preventing some SQL injections. But other admins disable it, as dealing with their data is each developper’s responsibility: the language must not modify those on the fly!
And now, a given application works flawlessly on one server, but will totally screw up on another one – either injecting some \ everywhere, or exploding on half SQL queries! All that because it won’t have been specifically developped to take into account different combinations of configuration options.
You were dreaming about this? Welcome to magic quotes5 hell!
In the same way, do you remember register_globals, with variables magically appearing in your scripts, when that directive was enabled? Wasn’t it hell too?
Let’s come back to this century: each time a configuration directive is added to PHP6, it means:
- Several code branches must be tested, debugged and maintained. Maintenance, for a feature in a language as used PHP, goes for 10 years. And more!
- More documentation to write, on one hand – and to read and understand, on the other hand.
- More work, to ensure each application7 works with each combination of parameters.
- In case of a problem, how long before realising some strange behavior is caused by an unusual or unexpected value for a specific configuration directive? Or, worse, by an unusual combination of values for several odd configuration directives?
Good thing is, developpers working on PHP know about those problems and tend to avoid adding new INI directives (of this kind) without solid reasons. They also provide two php.ini-development and php.ini-production files, with good configuration values – and you should stay close to those.
In any case, before suggesting « but they could allow us to enable or not this feature with a simple INI directive » for ideas as critical as a weak or strict typing mecanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?
And now, let’s repeat after me: « INI directives are evil! »
-
Because it might break backward-compatibility, because it would change the way of the language, because some don’t like it, because some don’t want it… ↩︎
-
I’ll let you guess which language I’m thinking about ^^. But what I’m writing here, maybe generalizing a bit, can be applied to others! ↩︎
-
Please note this is my interpretation of things, many years after the events: I’m not sure I even knew about PHP when these choices were made. Maybe things happenned a bit differently! But the effect (and perception some have of the language) remains! ↩︎
-
Or not (that much?), actually… ↩︎
-
As PHP aims to minimize BC-break between each successive version, years have been necessary before we could get rid of this good-bad idea – and the accompagnying configuration and behavior differences! ↩︎
-
It’s also true for pretty much any piece of software, BTW ;-) ↩︎
-
Especially for software, open-source or not, that can be downloaded and installed on many servers – with sysadmins who all have their own way of configuring them! ↩︎
