Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <48C16F05.9090305@zend.com>
Date: Fri, 05 Sep 2008 10:40:21 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Stan Vassilev | FM <sv_forums@fmethod.com>
CC: Antony Dovgal <tony@daylessday.org>, 
 PHP Internals List <internals@lists.php.net>
References: <20080904190717.aaz97tz688oogc4c@horde.chinstrap.eu> <48C01A91.6010501@daylessday.org> <1F1F55D1526B4BA1999B314C72CF56A6@pc> <48C0D927.7050600@daylessday.org> <928F85B0BF8247B197E9924A6D40CB6A@pc> <48C1120A.6090207@daylessday.org> <B48D550AC0964979A8124244D349CAF4@pc>
In-Reply-To: <B48D550AC0964979A8124244D349CAF4@pc>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] ini-parsing, double quotes, windows in 5.3
From: stas@zend.com (Stanislav Malyshev)

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
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com