On 2010-10-22 11:35 PDT, Wan-Teh Chang wrote: > On Thu, Oct 21, 2010 at 3:53 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: >> I'd say the interfaces to those functions (more precisely, their >> signatures) are quite frozen. The mp_int bignum package API is so >> frozen as to have become something of a standard of its own. There >> are now at least 3 different implementations known to me that are all >> API compatible, differing only in the content of the (opaque) mp_int >> structure itself. >> >> Speaking only for myself, I have no objection to offering the mp_int >> bignum API as a "public" API out of freebl3. They're not presently >> exported from the freebl shared lib at all, but IMO, they could be. >> We merely wanted to minimize the exported API. > > We also need to undo some processor-version-specific type definitions. > An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit > is defined differently for different versions of the SPARC v9a processors: > http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/Makefile&rev=1.115&mark=420-432#420
Hmm. The mp_int struct itself should be opaque in a public definition. So there shuold be no need to change the machine-dependent definitions of the contents of that struct (including the array to which it points). But I know that mp_digit is also used for types in the function signatures, and that IS an issue... I think this says that the task is feasible but requires more time to think about all its implications. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
