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
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.255.255.0';
I missed the fact that array_values() returns an ar
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
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: ""Ron Korving"" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To:
Sent: Tuesday, September 06, 2005 4:48 AM
Subject: Re: crc32
W
With a crc function the way you propose it, such a filter could be
effectively made in userspace, but you could of course also implement such a
filter in the core of php which could do the same trick. Maybe both would be
nice.
Ron
"Wojtek Meler" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL
Ron Korving wrote:
Wouldn't it be more practical to implement these as stream filters?
Sure - I was not aware PHP5 streams - I'm still using PHP4
string.base64 is good choice. But I'm not sure if crc fit to streams.
You can always implement fast userland filter with such function ;) .
Wojtek
Wouldn't it be more practical to implement these as stream filters?
Ron
"Wojtek Meler" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> I've patched original crc32 PHP function to allow incremental crc32
> counting.
> It touches only a few lines of original code.
> New crc32 funct
Oops !!! I've left old license header. Here is smaller clean version that apply
to CVS HEAD.
Index: crc32.c
===
RCS file: /repository/php-src/ext/standard/crc32.c,v
retrieving revision 1.16
diff -u -r1.16 crc32.c
--- crc32.c 3 Aug 20
> crc32, md5 and sha1 functions, implemented in PHP, are widely used for
> computing "fingerprint" of any data. But current implementation has not
very
> good limitation - there is no way to get/set current state vector of these
> functions. So, we have to pass whole amount of data as argument of t
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;
>
On Sun, 13 Jun 2004 11:24:12 +0200, Ard Biesheuvel <[EMAIL PROTECTED]> wrote:
First of all, crc32tab is no longer in the .text segment, so it will not
be shared between forked processes, taking more memory space than
necessary. Each process will have to initialise it as well, so the init
loop
Alexander Valyalkin wrote:
1) Automatic initialization of crc32tab[] at first call.
So, the file crc32.h with definition of this tab is not
nessesary any more now.
First of all, crc32tab is no longer in the .text segment, so it will not
be shared between forked processes, taking more memory
28 matches
Mail list logo
