Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71105
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.44 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <09595ef77b25972feab8e047bebdd37c.squirrel@webmail.klapt.com>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
	<CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
	<a0a503d9f023c87e79ad1bb877d64789.squirrel@webmail.klapt.com>
	<CADNQb0VaDeT==WAcN_rsyp61L4bf14VvcmgpXL70E5i2T5G97g@mail.gmail.com>
	<f3d0ad6a6b6575da7929efc71116eaa6.squirrel@webmail.klapt.com>
	<CAEKnhAGi0FBTvvvDa1cK6OwS_9bAkxHGCOAhUg2xTjMAcYpXBA@mail.gmail.com>
	<10f19e40b03ee19837010a988eb05706.squirrel@webmail.klapt.com>
	<CAEKnhAHwfbz1MTBGT9R3nvPwU9Mx8EU2r0qcO4VJJ7R=WaT4MQ@mail.gmail.com>
	<2e9df2840916d6e72255764a08086e57.squirrel@webmail.klapt.com>
	<CAEKnhAFNDk4Azm7Yh5Ms5=uRAnozQwgktR-uRMSVNUqK_QDFpg@mail.gmail.com>
	<f0f4f27f8196b699f37e60918c19942d.squirrel@webmail.klapt.com>
	<CAEKnhAHhs4fwCwGkvoO8v0Sb4BoHdAhrKiuOA+E_WKh2PRaBkA@mail.gmail.com>
	<09595ef77b25972feab8e047bebdd37c.squirrel@webmail.klapt.com>
Date: Sun, 12 Jan 2014 21:18:44 +0000
Message-ID: <CAEKnhAHJ=KmtgpNAY8ajXGB8-mZVoD=THpb6-oimf+R4k8QZJA@mail.gmail.com>
To: Anatol Belski <ab@php.net>
Cc: Hannes Magnusson <hannes.magnusson@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113386e80b121804efcc8117
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: bukka@php.net (Jakub Zelenka)

--001a113386e80b121804efcc8117
Content-Type: text/plain; charset=ISO-8859-1

Hi Anatol,

On Sat, Jan 11, 2014 at 7:34 PM, Anatol Belski <ab@php.net> wrote:

> If a library expects long, in the new code that's the issue on 32 bit
> windows only. So yes, probably the way you describe is plausible, check
> PHP_WIN32 and PHP_API_VERSION. Honestly, right at the place where I sit, I
> can't remember any library working with long (well, timeval struct and so
> on, not really libs). There are int, size_t, int64_t, ... so while the
> case you describe is of course possible, it's rather an exception. Usually
> a simple runtime range check will be good enough, if needed at all.
>
>
Actually there is one big library where you can find it. It's OpenSSL which
is why I was asking about it.. :) There are quite a few places where it's
used. The main ones are following:

- ASN.1 API functions (I plan to completely wrap it :) ) where it's used
for data length.
- BIO_ctrl for length parameter (BIO_ctrl is a definition result for many
macros like BIO_set_mem_buf, BIO_set_buffer_size, BIO_set_write_buf_size...)
- Big numbers - there is a situation a bit more complicated but unsigned
long is used (there will be necessary some other checks anyway so it's not
an issue)

I think that would be good to have a look to the other exts and double
check if used libs have long parameters for data lengths. If not, then I
agree with you that there is no point to do casting to long with warnings
just because of OpenSSL.

However it would be good to define in compat header a macro for checking
that long != php_int_t . I know that it's currently only _WIN64 but if you
implement enabling 64bit on 32bit platform (future scope in the RFC :) ),
then there will be an extra definition.

Cheers

Jakub

--001a113386e80b121804efcc8117--