Hi,
On Sat, Sep 7, 2013 at 6:44 PM, Marco Schuster wrote:
>
> I ran into 32-bit problems, too, when working with >2GB files (in this
> case, raw DVD ISO images) on a 32-bit system (I couldn't find a
> reliable(!!) way to read a 4-byte absolute offset and seek to it).
> Of course, this warning is
Hi,
I ran into 32-bit problems, too, when working with >2GB files (in this
case, raw DVD ISO images) on a 32-bit system (I couldn't find a
reliable(!!) way to read a 4-byte absolute offset and seek to it).
Of course, this warning is mentioned in the manpage, but really, not
having at least a class
if I wanted strings or something else, that would be simple enough -
sprintf() will do the job.
in my case, I needed a scalar value that I can actually persist to the
database.
On Mon, Sep 2, 2013 at 4:21 PM, Stas Malyshev
wrote:
> Hi!
>
> > What I'm suggesting is simply a set of alternative f
Hi!
> What I'm suggesting is simply a set of alternative functions to
> ip2long() and crc32() that return consistent values on all platforms,
> e.g. 32-bit signed integer values - a couple of new functions and a
> couple of quick updates to the documentation explaining why you might
> want to use
No, just this thread of e-mails.
What I'm suggesting is simply a set of alternative functions to ip2long()
and crc32() that return consistent values on all platforms, e.g. 32-bit
signed integer values - a couple of new functions and a couple of quick
updates to the documentation explaining why you
Hi!
> Yes, all of these problems can be solved - I am well aware of that. I am
> also painfully aware of how much time it can take to solve them reliably.
>
> I just would like to see a solution rather than a bunch of work-arounds -
> not for my own sake, my problem is solved, but for the sake of
Matthew,
Yes, all of these problems can be solved - I am well aware of that. I am
also painfully aware of how much time it can take to solve them reliably.
I just would like to see a solution rather than a bunch of work-arounds -
not for my own sake, my problem is solved, but for the sake of ever
Hi,
On 30 Aug, 2013, at 11:29 PM, Rasmus Schultz wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('2
On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz wrote:
> array(2) {
> [2130706433]=>
> string(3) "foo"
> ["4294967040"]=>
> string(3) "bar"
> }
>
> The keys are now two different types (string vs int) on 32-bit platforms,
> which leads to problems with strict comparison.
>
Prefix your key
Perhaps this illustrates the problem better:
$value = sprintf('%u', ip2long('255.255.255.0'));
var_dump($value, (int) $value);
$a = array();
$a[$value] = 'foo';
var_dump($a);
Output on 64-bit:
string(10) "4294967040"
int(4294967040)
array(1) {
[4294967040]=>
string(3) "foo"
}
No problem.
Matthew,
To give another example:
var_dump(array(sprintf('%u', ip2long('127.0.0.1')) => 'foo', sprintf('%u',
ip2long('255.255.255.0')) => 'bar'));
array(2) {
[2130706433]=>
string(3) "foo"
["4294967040"]=>
string(3) "bar"
}
The keys are now two different types (string vs int) on 32-bit
On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('255.2
Hello Sara,
nice and helpfull idea
best regards
marcus
Tuesday, September 6, 2005, 3:57:38 PM, you wrote:
> I'd suggest a set of filters as an add-on to the mhash extension:
> mhash.crc32
> mhash.md5
> mhash.sha1
> mhash.sha256
> etc
> -Sara
> - Original Message -
> From: ""Ro
On Mon, 2004-06-14 at 12:48 +0200, Christian Schneider wrote:
> Alexander Valyalkin wrote:
> > It is only idle talk. Can you provide any string from my code which
> > violates your "coding standards"?
>
> Calm down. As I said before (obviously not clearly enough, I was hoping
> one of the 'projec
On Mon, 14 Jun 2004 13:49:16 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
Alexander Valyalkin wrote:
:) Are you sure? I'm not. Look on declaration of [nr] variable:
int nr;
And answer, please, which value will be assigned to nr, if length of
a string will be greater than 0x7fff on 32-bit ar
Alexander Valyalkin wrote:
:) Are you sure? I'm not. Look on declaration of [nr] variable:
int nr;
And answer, please, which value will be assigned to nr, if length of
a string will be greater than 0x7fff on 32-bit architecture?
The funny thing is that in this case, it doesn't matter if 'nr' is
Alexander Valyalkin wrote:
It is only idle talk. Can you provide any string from my code which
violates your "coding standards"?
Calm down. As I said before (obviously not clearly enough, I was hoping
one of the 'project managers' would do that for me ;-)) you are missing
the point why people rej
On Mon, 14 Jun 2004 11:00:33 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]>
wrote:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &p, &nr)
==
FAILURE) {
return;
}
/* !!! there is no error check nr < 0 */
Of course not, that's pointless as a string can never
On Mon, 14 Jun 2004, Alexander Valyalkin wrote:
> Thank you for good explanation and comments.
> Now I understood that the current crc32 implementation is better than mine.
> But it consists some ugly bugs (read my comments):
> PHP_NAMED_FUNCTION(php_if_crc32)
> {
> unsigned int crc = ~0;
>
19 matches
Mail list logo
