Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10438 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99399 invoked by uid 1010); 14 Jun 2004 12:27:44 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 99355 invoked by uid 1007); 14 Jun 2004 12:27:44 -0000 To: internals@lists.php.net Date: Mon, 14 Jun 2004 15:26:56 +0300 References: <40CC1D3C.9070605@php.net> <20040614114909.68658.qmail@pb1.pair.com> Organization: none Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/7.50 (Win32, build 3778) X-Posted-By: 217.23.116.150 Subject: Re: [PHP-DEV] Re: crc32() improvements From: valyala@tut.by ("Alexander Valyalkin") On Mon, 14 Jun 2004 13:49:16 +0200, Ard Biesheuvel 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 0x7fffffff on 32-bit architecture? > > The funny thing is that in this case, it doesn't matter if 'nr' is > signed or unsigned, as it is decremented by 1 until it becomes zero. > This will also work as expected for negative values. So the function > will be correct for strings of up to 4GB. > Yes, it is very funny :) But only in this case. How about another places in the sources? >> It is only idle talk. Can you provide any string from my code which >> violates your "coding standards"? > > All of the one-liners, basically. You should use more braces & > whitespace. > Well, this code is better than old one: =========cut========== PHP_NAMED_FUNCTION(php_if_crc32) { unsigned int crc = ~0; unsigned char *p; int nr; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", (char **)&p, &nr) == FAILURE) { return; } if (nr) { do { crc = (crc >> 8) ^ crc32tab[(unsigned char)crc ^ *p++]; } while (--nr); } RETVAL_LONG(~crc); } =========cut========== >>> And there is no reason to expand that macro at all >> Is significant speed improvement silly reason for you? > > You mean at compile-time ? No, I meant the real speed improvement by 40% at run-time. > Macros are expanded by the pre-processor, so the expanded code that is > processed by the compiler is *identical* to your inlined code. So no > speed increase here. > Compare the macros with my inline code: #define CRC32(crc, ch) (crc = (crc >> 8) ^ crc32tab[(crc ^ (ch)) & 0xff]) crc = (crc >> 8) ^ crc32tab[(unsigned char)crc ^ *p++]; Are they identical? -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/