Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48329 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35932 invoked from network); 18 May 2010 21:37:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 May 2010 21:37:16 -0000 X-Host-Fingerprint: 209.131.62.146 nat-dip11.cfw-b-gci.corp.yahoo.com Received: from [209.131.62.146] ([209.131.62.146:1265] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D8/91-27340-B8803FB4 for ; Tue, 18 May 2010 17:37:15 -0400 Message-ID: To: internals@lists.php.net Date: Tue, 18 May 2010 14:37:11 -0700 User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 209.131.62.146 Subject: Re: [PHP-DEV] openssl_(en|de)crypt missing IV From: pollita@php.net (Sara Golemon) >> The only BC break is the warning raised when using openssl_encrypt() without >> an IV. Given the extremely bad practice using a NULL IV represents, I think >> this is a reasonable course of action. > > It changes the signature making the fifth argument a complete > different thing. I strongly disagree with this strategy, even if I can > understand your reasoning. We can't begin to "fix" things by changing > existing API signatures, that's going to end badly. > What do you mean by "making the fifth argument a complete different thing"? Different to what? The current signature only has four arguments. This adds an optional argument which, by itself, is not BC breaking. If you really feel strongly about it, I can add it as a new function entirely, but the duplication seems very unnecessary to me. I'm all for preserving BC, but when one does so at the sacrifice of reason* it just makes us all look a bit silly. > To define a new and clean API is not only BC but may also allow > obvious naming. And last but not least, it can then be merged in 5.3 > without worrying about any possible impact. > Absolutely true, and /possibly/ worth the "wtf" that comes with having two essentially identical functions. How would you feel about the trunk versions of the old functions (but not the 5.3 versions) gaining ZEND_ACC_DEPRECATED in that case? -Sara * Once again, the current 5.3 implementation is worthless, it is without worth, it has no value of any worth, it's worthless Dave.