Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71106
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.48 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAEKnhAHJ=KmtgpNAY8ajXGB8-mZVoD=THpb6-oimf+R4k8QZJA@mail.gmail.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>
	<CAEKnhAHJ=KmtgpNAY8ajXGB8-mZVoD=THpb6-oimf+R4k8QZJA@mail.gmail.com>
Date: Sun, 12 Jan 2014 23:23:49 +0000
Message-ID: <CAEKnhAHMsrfeXTOF52EZRrZdjDNE1-f_9894kvoSEx9XOBKmwg@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=047d7b6da24062193a04efce4009
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: bukka@php.net (Jakub Zelenka)

--047d7b6da24062193a04efce4009
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 12, 2014 at 9:18 PM, Jakub Zelenka <bukka@php.net> wrote:

> Hi Anatol,
>
> Jakub
> 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.
>
>
I was thinking a bit more what will be the consequences of asn1 and bio in
my ext for "l" flag and it won't be such a big issue regarding to zpp.
There are just few cases in asn1 (ASN1_INTEGER_set for example) and BIO
stuff will probably require mainly string conversions which is a bit
different issue...

What's the actually plan for keeping BC for "s" and "p"? Is it gonna be
zend_str_size from compat header and "s" and "p" aliases of "S" and "P"?

Something like...
...
char *s;
zend_str_size len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &s, &len) ==
FAILURE) { return; }
...

If so, I think that that would be a slightly bigger issue (size_t vs
int)...

There are only two solutions of zpp "s" that I think of:
1. check range (INT_MAX) and cast it to int (possibly throw warning if it's
out of range) -> that could result too many warning but it's safe
2. PHP version variable zend_str_size (see above) -> the same as discussed
for long but considerably more places where we will need to find out what
the zend_str_size really is.

What do you think?

Cheers

Jakub

--047d7b6da24062193a04efce4009--