Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38651
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 193.227.246.108 as permitted sender)
Message-ID: <486423F4.9080405@php.net>
Date: Fri, 27 Jun 2008 00:19:16 +0100
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Derick Rethans <derick@php.net>, internals <internals@lists.php.net>, 
 Sara Golemon <pollita@php.net>
References: <fe05d1540806011602sb0194b0i6e91a65aa5e85c0@mail.gmail.com>	 <alpine.DEB.0.98.0806021020480.10214@kossu.ez.no>	 <fe05d1540806020130m44eb8afs92a8257f8e3df1d4@mail.gmail.com>	 <4843CCB4.8050004@php.net> <fe05d1540806021006s7612ae83ke486adc27cc036ec@mail.gmail.com>
In-Reply-To: <fe05d1540806021006s7612ae83ke486adc27cc036ec@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Pierre Joye wrote: > On Mon, Jun 2, 2008 at 12:34 PM, Scott
	MacVicar <scottmac@php.net> wrote: >> Pierre Joye wrote: >>> On Mon, Jun
	2, 2008 at 10:21 AM, Derick Rethans <derick@php.net> wrote: >>>> On Mon, 2
	Jun 2008, Pierre Joye wrote: >>>> >>>>> While working on the windows ports,
	I asked Sara about the mhash >>>>> status in regard of the new shiny ext/hash.
	The plan is to remove >>>>> ext/hash completely and emulate it in ext/hash
	to keep the BC. It >>>>> could even a configuration flag if one likes to
	be sure to clean his >>>>> code to use only the hash APIs. >>>> The mhash
	extension features some more versions of some algorithms: >>>> http://mhash.sourceforge.net/
	But why bother changing it? >>> Which algo(s) (or algo version) is not supported
	by ext/hash? I did >>> not spot one after a quick read. >>> >> sha192 and
	sha224 >> snefru128 >> md2 >> >>>> I've not heard of any issues about ext/mhash.
	>>> My main reasons would be to do not have to maintain ext/mhash and the
	>>> libmhash Windows port. >>> >>> Cheers, >> I'm happy to see us removing
	a dependency, especially if it makes thigns >> easier to build on Windows.
	> > In case someone likes to do it, Scott has volunteered and has already
	> added some of the missing algo in hash. He will also add the BC layer.
	> > Cheers, [...] 
	Content analysis details:   (-1.9 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
Subject: Re: [PHP-DEV] Drop ext/mhash and add an emulation layer in ext/hash
 (5.3+), call for help
From: scottmac@php.net (Scott MacVicar)

Pierre Joye wrote:
> On Mon, Jun 2, 2008 at 12:34 PM, Scott MacVicar <scottmac@php.net> wrote:
>> Pierre Joye wrote:
>>> On Mon, Jun 2, 2008 at 10:21 AM, Derick Rethans <derick@php.net> wrote:
>>>> On Mon, 2 Jun 2008, Pierre Joye wrote:
>>>>
>>>>> While working on the windows ports, I asked Sara about the mhash
>>>>> status in regard of the new shiny ext/hash. The plan is to remove
>>>>> ext/hash completely and emulate it in ext/hash to keep the BC. It
>>>>> could even a configuration flag if one likes to be sure to clean his
>>>>> code to use only the hash APIs.
>>>> The mhash extension features some more versions of some algorithms:
>>>> http://mhash.sourceforge.net/ But why bother changing it?
>>> Which algo(s) (or algo version) is not supported by ext/hash? I did
>>> not spot one after a quick read.
>>>
>> sha192 and sha224
>> snefru128
>> md2
>>
>>>> I've not heard of any issues about ext/mhash.
>>> My main reasons would be to do not have to maintain ext/mhash and  the
>>> libmhash Windows port.
>>>
>>> Cheers,
>> I'm happy to see us removing a dependency, especially if it makes thigns
>> easier to build on Windows.
> 
> In case someone likes to do it, Scott has volunteered and has already
> added some of the missing algo in hash. He will also add the BC layer.
> 
> Cheers,

ext/mhash now wraps around ext/hash in 5.3

I'd like to recommend we add a E_DEPRECATED to anything mhash_* related 
and drop the extension for 6?

I'll add the BC layer tomorrow to 6.0 regardless.

Scott