Mailing-List: contact commits-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apr.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <43975B65.3030004@rowe-clan.net>
Date: Wed, 07 Dec 2005 16:00:05 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
MIME-Version: 1.0
To: dev@apr.apache.org
CC: commits@apr.apache.org
Subject: Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c
 sha2.h
 sha2_glue.c
References: <20051207182913.89871.qmail@minotaur.apache.org>
 <4397537B.4010805@rowe-clan.net>
 <5F9F85E6-CB89-4572-86CB-AF982CED0F6A@red-bean.com>
In-Reply-To: <5F9F85E6-CB89-4572-86CB-AF982CED0F6A@red-bean.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brian W. Fitzpatrick wrote:
> 
> On Dec 7, 2005, at 3:26 PM, William A. Rowe, Jr. wrote:
> 
>> fitz@apache.org wrote:
>>
>>> Prefix non-static symbols with 'apr__' to avoid namespace conflicts.
>>> * random/unix/sha2.h, random/unix/sha2_glue.c, random/unix/sha2.c:
>>>   Rename SHA256_Init, SHA256_Update, SHA256_Final, SHA256_Transform,
>>>   SHA384_Init, SHA512_Init, SHA512_Final, SHA384_Final,  SHA512_Update,
>>>   SHA384_Update, and SHA512_Transform, , to apr__SHA256_Init,
>>>   apr__SHA256_Update, apr__SHA256_Final, apr__SHA256_Transform,
>>>   apr__SHA384_Init, apr__SHA512_Init, apr__SHA512_Final,
>>>   apr__SHA384_Final, apr__SHA512_Update, apr__SHA384_Update, and
>>>   apr__SHA512_Transform.
>>
>> Are these in fact 'not for external use'?
> 
> That is correct.  You may notice that there are no symbols for these  
> functions in APR's public headers.

Correct, but why? ...

>> If they are for export, why the choice of the extra underbar?   Given 
>> that we
>> do export MD5 for everyone's use, and the universal contention is  
>> that MD5 is,
>> if not today, then, dead by tomorrow for most security purposes.

I didn't see your comment to this, it seems these -should- be exported to me.

>> It seems these should be public, and the '__'s will inevitably  
>> confuse some
>> devs, as well as not following our conventions.
> 
> Then we should document it as our convention. :-)

Or something +1... _apr_foo or apr__foo is fine here.

We should also spell out that any such __ entry points are NOT subject to our
revisioning policy, shoot yourself in the foot at your own risk.

Bill