Hi Anatol,
On Sat, Jan 11, 2014 at 7:34 PM, Anatol Belski <[email protected]> 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