Hi,
the branch with size_t for string length and 64 bit integer replacement
for long datatype was brought so far. This branch is based on the one
started by Anthony Ferrara.
Compiled with --disable-all --enable-cli this functionality is already
available. Except of a couple of edge cases, the tests pass on both 64 bit
Windows and Linux. The implementation is ready as a solid base for the
further porting. There are several new macros and typedefs to handle 64
bit compatibility. All those are placeholders which can be easily renamed
later, if needed. There is a wiki page indicating the current progress and
containing quick start instructions:
https://wiki.php.net/rfc/string-size_t/progress
As the base does exist now, I'd like to call the maintainers and
developers to participate on further porting of the core extensions and
SAPIs. Many of those should be easy to convert. Any reviews and comments
on what is done are of course welcome, too.
The new era of PHP is coming, do your part! :)
Cheers
Anatol
Hi,
the branch with size_t for string length and 64 bit integer replacement
for long datatype was brought so far. This branch is based on the one
started by Anthony Ferrara.Compiled with --disable-all --enable-cli this functionality is already
available. Except of a couple of edge cases, the tests pass on both 64 bit
Windows and Linux. The implementation is ready as a solid base for the
further porting. There are several new macros and typedefs to handle 64
bit compatibility. All those are placeholders which can be easily renamed
later, if needed. There is a wiki page indicating the current progress and
containing quick start instructions:https://wiki.php.net/rfc/string-size_t/progress
As the base does exist now, I'd like to call the maintainers and
developers to participate on further porting of the core extensions and
SAPIs. Many of those should be easy to convert. Any reviews and comments
on what is done are of course welcome, too.The new era of PHP is coming, do your part! :)
Thanks Anatol, awesome effort!
I have ext/hash sitting here, but still have to rebase to the
git.php.net branch...
--
Regards,
Mike
Hi,
the branch with size_t for string length and 64 bit integer replacement
for long datatype was brought so far. This branch is based on the one
started by Anthony Ferrara.Compiled with --disable-all --enable-cli this functionality is already
available. Except of a couple of edge cases, the tests pass on both 64
bit Windows and Linux. The implementation is ready as a solid base for
the further porting. There are several new macros and typedefs to handle
64
bit compatibility. All those are placeholders which can be easily
renamed later, if needed. There is a wiki page indicating the current
progress and containing quick start instructions:https://wiki.php.net/rfc/string-size_t/progress
As the base does exist now, I'd like to call the maintainers and
developers to participate on further porting of the core extensions and
SAPIs. Many of those should be easy to convert. Any reviews and
comments on what is done are of course welcome, too.The new era of PHP is coming, do your part! :)
Thanks Anatol, awesome effort!
I have ext/hash sitting here, but still have to rebase to the
git.php.net branch...
Hi Michael,
I've marked ext/hash as 'in progress' on the wiki. Had to do some basic
fixes to it though in order to work on ext/session. Could you please merge
what is done by you then?
Thanks
Anatol
Hi,
the branch with size_t for string length and 64 bit integer replacement
for long datatype was brought so far. This branch is based on the one
started by Anthony Ferrara.Compiled with --disable-all --enable-cli this functionality is already
available. Except of a couple of edge cases, the tests pass on both 64 bit
Windows and Linux. The implementation is ready as a solid base for the
further porting. There are several new macros and typedefs to handle 64
bit compatibility. All those are placeholders which can be easily renamed
later, if needed. There is a wiki page indicating the current progress and
containing quick start instructions:https://wiki.php.net/rfc/string-size_t/progress
As the base does exist now, I'd like to call the maintainers and
developers to participate on further porting of the core extensions and
SAPIs. Many of those should be easy to convert. Any reviews and comments
on what is done are of course welcome, too.The new era of PHP is coming, do your part! :)
Hi,
I have been playing with openssl a bit and made it work with this
configuration:
--disable-all --enable-cli --enable-debug --with-openssl
The commit is here
https://github.com/bukka/php-src/commit/215811e3fdb7b4f2786576851c8687c6249c4725
It's just an initial work but it works fine for all tests. However there
are lots of issues that need to be properly tested. I made notes about all
possible issues that could be a problem:
https://gist.github.com/bukka/7617548
Lots of them are just possible loss of data that won't be really
problematic but testing is required anyway IMHO. But some issues could be a
problem and they need a proper testing.
I currently work on my php-crypto ext that I plan to propose for PECL soon.
So I will be doing testing for more versions of OpenSSL anyway. I could
prepare some tests for edge cases and do it together though.
Let me know what you think about the patch!
Thanks
Regards
Jakub
Hi Jakub,
I have been playing with openssl a bit and made it work with this
configuration:--disable-all --enable-cli --enable-debug --with-openssl
The commit is here
https://github.com/bukka/php-src/commit/215811e3fdb7b4f2786576851c8687c62
49c4725It's just an initial work but it works fine for all tests. However there
are lots of issues that need to be properly tested. I made notes about all
possible issues that could be a problem:https://gist.github.com/bukka/7617548
Lots of them are just possible loss of data that won't be really
problematic but testing is required anyway IMHO. But some issues could be
a problem and they need a proper testing.I currently work on my php-crypto ext that I plan to propose for PECL
soon. So I will be doing testing for more versions of OpenSSL anyway. I
could prepare some tests for edge cases and do it together though.Let me know what you think about the patch!
your patch looks fine. Unfortunately I've overseen your mail in the daily
flood and made some changes to openssl too. Why didn't you update the wiki
page by going on? It's exactly for the purpose of knowing what's currently
going on :) In any case, could you please merge with the current state and
do a PR? I'll merge it then.
One thing though about openssl and issues you mention in the gist - the
'int' vs. php_int_t overflows on 64 bit should be fixed on run time
checking against INT_MAX. Maybe that's what you could extend for the
openssl ext. That's an issue in many other libs too.
Thanks for you work
Anatol
Hi Anatol
your patch looks fine. Unfortunately I've overseen your mail in the daily
flood and made some changes to openssl too. Why didn't you update the wiki
page by going on? It's exactly for the purpose of knowing what's currently
going on :) In any case, could you please merge with the current state and
do a PR? I'll merge it then.One thing though about openssl and issues you mention in the gist - the
'int' vs. php_int_t overflows on 64 bit should be fixed on run time
checking against INT_MAX. Maybe that's what you could extend for the
openssl ext. That's an issue in many other libs too.Thanks for you work
Anatol
I quickly looked on your commit and think that we mostly did the same stuff
:). Sorry for not updating the wiki, thought that will be better if I email
you first.
However there few extra fixes in my commit and some extra fixes in your
commits so I will merge them.
php_int_t vs int fixes will be quite easy. I'll do that. The bigger task is
int vs size_t (zend_str_size...) - signed vs unsigned. For some cases
(encryption, digest and other ctx updates) this can be fixed by splitting
the processing into more ctx updates. I think this could be useful on 32bit
when someone tries to encrypt more than 1 << 32 string. In that case, using
one update (as it is now) would fail. Other cases should probably generate
an error as there are not useful anyway. There few other case that I need
to look at as well (bio_buf_st->length, ASN_STRING length retval...).
I can assign it to myself in the wiki and set status "in progress" and when
it's done, I will update it and send PR. Is that ok?
Jakub
1 << 32 string.
sorry, of course I meant 1 << 31 :)
Hi Anatol
your patch looks fine. Unfortunately I've overseen your mail in the
daily flood and made some changes to openssl too. Why didn't you update
the wiki page by going on? It's exactly for the purpose of knowing
what's currently going on :) In any case, could you please merge with
the current state and do a PR? I'll merge it then.One thing though about openssl and issues you mention in the gist - the
'int' vs. php_int_t overflows on 64 bit should be fixed on run time
checking against INT_MAX. Maybe that's what you could extend for the
openssl ext. That's an issue in many other libs too.Thanks for you work
Anatol
I quickly looked on your commit and think that we mostly did the same
stuff :). Sorry for not updating the wiki, thought that will be better if
I email
you first.However there few extra fixes in my commit and some extra fixes in your
commits so I will merge them.php_int_t vs int fixes will be quite easy. I'll do that. The bigger task
is int vs size_t (zend_str_size...) - signed vs unsigned. For some cases
(encryption, digest and other ctx updates) this can be fixed by splitting
the processing into more ctx updates. I think this could be useful on
32bit
when someone tries to encrypt more than 1 << 32 string. In that case,
using one update (as it is now) would fail. Other cases should probably
generate an error as there are not useful anyway. There few other case
that I need to look at as well (bio_buf_st->length, ASN_STRING length
retval...).I can assign it to myself in the wiki and set status "in progress" and
when it's done, I will update it and send PR. Is that ok?Jakub
Jakub,
the ctx update issue might be interesting for the current codebase as
well, I think. A simpler way were the range check for INT_MAX as it's
always possible to pass a smaller chunk from the userland. The size_t vs.
signed might can get an issue of course, that's the common thread of
course so should be fixed where applicable.
I could only welcome you to update the wiki with the task you can take on,
whether nicer or simpler solution :)
Thanks
Anatol