Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10437 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68856 invoked by uid 1010); 14 Jun 2004 11:49:10 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 68659 invoked by uid 1007); 14 Jun 2004 11:49:09 -0000 Message-ID: <20040614114909.68658.qmail@pb1.pair.com> To: internals@lists.php.net Date: Mon, 14 Jun 2004 13:49:16 +0200 User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <40CC1D3C.9070605@php.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 80.126.21.70 Subject: Re: [PHP-DEV] Re: crc32() improvements From: abies@php.net (Ard Biesheuvel) 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. > 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. > By the way, your "coding standards" violates C standards on type > of string (and any other byte arrays) length. Why are you use int > instead of size_t?: Why should PHP strings conform to C string standards ? >> And there is no reason to expand that macro at all > > Is significant speed improvement silly reason for you? > You mean at compile-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. -- Ard