apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian W. Fitzpatrick" <f...@red-bean.com>
Subject Re: svn commit: r354824 - in /apr/apr/trunk/random/unix: sha2.c sha2.h sha2_glue.c
Date Wed, 07 Dec 2005 22:40:52 GMT

On Dec 7, 2005, at 4:00 PM, William A. Rowe, Jr. wrote:

> 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? ...

*sigh*  They're merely meant to be consumed by the yet unfinished  
PRNG.  Ask Ben Laurie for details.

>>> 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.

And I'm telling you that they should NOT be exported.

>>> 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.

If they're not in the public headers, I don't think it's a problem.

This is not a big deal--I am correcting an oversight.

-Fitz

Mime
View raw message