Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70840
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.160.43 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <52B76720.4030403@sugarcrm.com>
References: <CAESVnVqAukZUar4xMk5Pr52u83m2RFq3iN=DRjJM18-izdqX=A@mail.gmail.com>
	<52B76720.4030403@sugarcrm.com>
Date: Sun, 22 Dec 2013 15:10:08 -0800
Message-ID: <CAESVnVrg5qJjmdOX3i6YKwu+YbqY+M7XsEWKGShjTE_vNoBEAg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [RFC] Base Conversion Clowniness
From: pollita@php.net (Sara Golemon)

> Just a little note - I don't think any option that adds warnings where
> there were not warnings is acceptable in this case for any stable
> version. There are dozens of ways extra warning could break an existing
> app.
>
I can see the argument for that, though anything depending on buggy
conversion is probably broken.

> Also, wouldn't simple regexp or filter or is_numeric check solve this
> issue while allowing much more flexible reaction to wrong data? I'm not
> sure that more warnings is better than more data checking.
>
Sure, one could validate before conversion with something like:

if (strcmp($val, base_convert($val, $base, $base))) {
  /* $val isn't purely in base $base */
} else {
  $newval = base_convert($val, $base, $newbase);
}

And a proper app *should* have logic like that regardless.

However I do think that when apps don't apply such forward-thinking
logic, we should be prepared to be noisy about it (as we do with an
fopen() call which wasn't preceeded by an is_readable()/is_writable()
check)

-Sara