On 30.03.2011 19:19, Wan-Teh Chang wrote: > Another option is to fix security/nss/lib/jar so that it doesn't > use the NSS_X86_OR_X64 macro. lib/jar is only used by > the NSS command-line tools modutil and signutil, so it isn't > important to rely on x86/x86_64 processors' ability to do > unaligned memory access.
Right, I had another look at libjar, and there's only one place in the code which relies on NSS_X86_OR_X64, in jarfile.c: > #ifdef NSS_X86_OR_X64 > #define x86ShortToUint32(ii) ((const PRUint32)*((const PRUint16 *)(ii))) > #define x86LongToUint32(ii) (*(const PRUint32 *)(ii)) > #else > static PRUint32 > x86ShortToUint32(const void *ii); > > static PRUint32 > x86LongToUint32(const void *ll); > #endif (later on, there are implementations of x86ShortToUint32 and x86LongToUint32 which simulate "an x86 (little endian, unaligned) uint fetch from any address") If we agree that we can sacrifice this optimization for x86 in jarfile.c, then it seems fairly straightforward to nuke NSS_X86_OR_X64 from libjar, so that there would be no further obstacle to using freebl/blconfig.h (which, IMO, seems preferrable to putting things into the public secport.h header). Kaspar -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
