Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66749
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.212.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <edc2ace420bf45c9f1a9d9a5fd2b4069.squirrel@webmail.klapt.com>
References: <56994bc16a23a22f5e1b71c94b792dce.squirrel@webmail.klapt.com>
	<CA+9eiLu3XjHA_-2cPMCOx0NyvZ+gg15RAvbnHTSpUsoRdMZwjw@mail.gmail.com>
	<CA+9eiLt_WaH=cOJCS2xi0Z9iAkunSEjRjEf3ThCBHYw-cnaBNg@mail.gmail.com>
	<edc2ace420bf45c9f1a9d9a5fd2b4069.squirrel@webmail.klapt.com>
Date: Fri, 22 Mar 2013 13:08:29 +0400
Message-ID: <CA+9eiLs8tQ7YJx099sE-Byxgz6HNXoA6xNjsOHCo1MctuRYQrw@mail.gmail.com>
To: ab@php.net
Cc: internals <internals@lists.php.net>, Rasmus Lerdorf <rasmus@lerdorf.com>
Content-Type: multipart/alternative; boundary=20cf307cfbd6734d1704d87fccd3
Subject: Re: Fix for #64450
From: dmitry@zend.com (Dmitry Stogov)

--20cf307cfbd6734d1704d87fccd3
Content-Type: text/plain; charset=UTF-8

Thanks, now I understood. :)

anyway I see a problem. For example on x86_64 double is not always able to
keep a long number without precision lost.
May be you should receive arguments as zvals and use old or new code
depending on input types.

BTW: I'm not sure if rand() should be fixed at all.
According to http://php.net/manual/en/function.rand.php it should accept
integers and return integer.

Thanks. Dmitry.

On Fri, Mar 22, 2013 at 12:08 PM, Anatol Belski <ab@php.net> wrote:

> Dmitry,
>
> first of all thanks for taking a look :)
>
> The issue in a few words
> - mt_rand reads arguments as long
> - user pass a float from the userspace
> - zend_parse_parameters with 'l' casts to long
>
> Here's the essential snippet
> echo mt_rand(0,pow(10,12));
> PHP Warning:  mt_rand(): max(-727379968) is smaller than min(0)
>
> So reading as long would probably not work, in the first place because the
> input data exceeding LONG_MAX will be corrupted by the conversion. So what
> I did
> - read input as max precision possible, no corruption
> - calculate as well with double
> - return the old way int if it's in LONG_MAX range, otherwise return float
>
> Is there a solution I don't see (or do I get your suggestion wrong)? It's
> just essential to get the input as precise as it can be across PHP.
>
> Besides that what could be impacts changing input arg types in this
> concrete case? User probably wouldn't realize that at all.
>
> Thanks
>
> Anatol
>
> On Fri, March 22, 2013 07:40, Dmitry Stogov wrote:
> > Hi Anatol,
> >
> >
> > To be honest, I didn't understand all the details of the patch :)
> >
> >
> > However, I see a problem:
> > You changed the prototype of user level rand() function to receive double
> > arguments instead of long. I think it's disallowed, but you may get
> > arguments as longs and then convert them to double. Will it work?
> >
> >
> > Thanks. Dmitry.
> >
> >
> > On Thu, Mar 21, 2013 at 9:26 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> >
> >
> >> I'll able to look only tomorrow morning.
> >>
> >>
> >> Thanks. Dmitry.
> >>
> >>
> >>
> >> On Thu, Mar 21, 2013 at 8:46 PM, Anatol Belski <ab@php.net> wrote:
> >>
> >>
> >>> Hi Dmitry,
> >>>
> >>>
> >>> I developed a patch for this one
> >>> https://bugs.php.net/bug.php?id=64450 .
> >>> It's regarding to the long overflow in mt_rand(). The main idea is to
> >>> work with the args as double internally and then return php float if
> >>> it exceeds the LONG_MAX. I strived to let the old behavior to be
> >>> unchanged, all the older tests pass. Please take a look.
> >>>
> >>> Regards
> >>>
> >>>
> >>> Anatol
> >>>
> >>>
> >>
> >>
> >
>
>

--20cf307cfbd6734d1704d87fccd3--