apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Date Wed, 07 Dec 2005 22:00:05 GMT
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

Mime
View raw message