Hi,
On Wed, Feb 18, 2015 at 2:27 PM, François Laupretre <[email protected]> wrote:
> Hi Andrey,
>
>> De : Andrey Andreev [mailto:[email protected]]
>>
>> I too am curious about the potential issue with "123" to 123
>> specifically, although it could be seen as a subset of another problem
>> that is solved with strict hints - numeric-character string
>> identifiers being erroneously treated as integers.
>
> Please give use cases. Do you want to support '0xhexa' strings ? that's
> possible. We are not only restricting possible conversions, we can also
> support additional syntaxes. Just give use cases for what you think should be
> enabled or disabled, compared to the current behavior.
>
> The only change we have in list so far about (string -> number) is rejecting
> trailing chars (but accepting trailing blanks).
>
> We are in the process of changing these rules so, please give examples of '
> numeric-character string identifiers being erroneously treated as integers'.
> If you mean '7 years', it's in list already. If others, tell us.
>
>> That is especially bad when such identifiers are in fact generated as
>> integers first so that they are incremental, but the
>> program/database/business logic requires them to be fixed-length
>> strings and/or in hexadecimal format. In such cases, even silently
>> discarding leading zeros can prove to be problematic, while in the
>> case of hexadecimal representations you'd need more than 10 data
>> samples to notice the problem if you don't use a strict hint.
>
> Do you mean we should accept hexadecimal string as int ? why not ? Give exact
> syntax(es) you want to support (except leading/trailing blanks, which are
> default now).
>
No, I meant the opposite ... I was trying to explain cases where a
weak hint would be insufficient. Sorry for not including examples in
my first mail, I did that in my next reply:
> Consider the following signature:
>
> function foo(int $bar) {}
>
> In the case of a *string* representation of a hexadecimal number, the
> following would error only on the last iteration with a weak hint, and
> on the very first if it was a strict hint:
>
> for ($i = 0; $i < 11; $i++)
> {
> foo(base_convert($i, 10, 16));
> }
>
> And when I said leading zeros, I was talking about fixed-length string
> identifiers such as '001', '002', etc. where you may *unintentionally*
> pass such a value to a function that deals with ... quantities, for
> example. A strict hint in that case would immediately catch this
> logical error while a weak hint would silently ignore the leading
> zeros and will happily treat the value as an integer. Again, the
> precondition here is that it's not an integer value that happens to be
> stored as a string, but a non-integer value that just looks like an
> integer.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
