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:
[EMAIL PROTECTED] 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
