Hi!

My proposal is to have a proper subset of the PHP string literal parsing, with the additional feature of warning when a user has

What for? Who would EVER need to have tab or newline in the path? Who this feature - recognizing \n and \r and \t in paths - would serve, what use case do you have for it?

instead you'd go for:

c:\\Documents\\toby  --OR--- c:/Documents/toby

I'd go for copy-pasting windows paths and not having to hand-edit them. Why should I? How it would make my life with PHP better?

Furthermore, parameters which specify pathnames can check for tabs (\t), newlines (\n, \r) and null (\0) and warn the user for a possible mistake, we don't have an actual scenario where a pathname contains tab or a newline, now do we.

Why warn if we know what the right thing to do is? There's no chance anybody has \n in path - or, for that matter, I have yet to see anybody needing \n in ANY ini value. If you do, you probably are severely misusing INI anyway. Why warn users about a bug (and yes, it is a bug - anything that works contrary to what user needs is) - instead of just fixing it?

The upside of all this is:

1) consistent handling of PHP.ini, other INI-s, and PHP string literals

Another hilarious abuse of "consistency". There's no any reason to treat different things the same for the sake of imaginary "consistency". php.ini and php code are different things, and should work according to their use cases, and not according to imaginary "consistency" concerns.

2) all those extra checks can be removed in PHP 6 or 7 after the changes "sink in" into the userbase and it becomes common knowledge that backslash needs to be escaped.

Escaping backslashes in INI files is stupid. Forcing users to do stupid work for "consistency" sake is double stupid.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]   http://www.zend.com/
(408)253-8829   MSN: [EMAIL PROTECTED]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to