Re: is_numeric_string an hexadecimal numbers ("123" == "0x7B")

From: Date: Tue, 17 Apr 2012 18:41:25 +0000
Subject: Re: is_numeric_string an hexadecimal numbers ("123" == "0x7B")
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 4/17/12 08:17, "Nikita Popov" <[email protected]> wrote:


>The last one is more problematic. It is explicitly documented as
>accepting hexadecimal numbers. In my eyes it too should not accept
>them, but I could imagine that people rely on this.

This always struck me as mistaken design. Why accept hex or decimal, but
not the other bases that PHP knows about? I can see a small number of
scenarios where having it accept hex input is definitely useful, but I
suspect that the vast majority of cases out there where it's used is in
validation routines expecting straightforward, base-10 numbers. And I know
that, of all such cases I've seen (and I've seen quite a few, since one of
our interview test questions implicitly covers it), most programmers are
blissfully ignorant of the hex support and unwittingly allow bad user data
to slip into their applications to become trusted data. Not good.

As I mentioned in my last message, I wouldn't be bothered if this behavior
were simply removed. I think it would affect a small number of people
knowingly relying on the feature, while it would fix probably many
thousands of bugs out there lurking in less-aware programmers' code. Even
better, though, might be to add a flag parameter that would give the
programmer explicit control over its behavior, including which bases to
allow (and including the bases currently MIA).

-Bob

--
Robert E. Williams, Jr.
Associate Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/







Notice: This communication, including attachments, may contain information that is confidential. It
constitutes non-public information intended to be conveyed only to the designated recipient(s). If
the reader or recipient of this communication is not the intended recipient, an employee or agent of
the intended recipient who is responsible for delivering it to the intended recipient, or if you
believe that you have received this communication in error, please notify the sender immediately by
return e-mail and promptly delete this e-mail, including attachments without reading or saving them
in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail,
including attachments, is prohibited and may be unlawful. If you have received this email in error,
please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if
any).


Thread (11 messages)

« previous php.internals (#60092) next »