PBC Library Manual 0.5.11 - Stanford Crypto Group
PBC Library Manual 0.5.11 - Stanford Crypto Group
PBC Library Manual 0.5.11 - Stanford Crypto Group
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 8. <strong>PBC</strong> internals<br />
I would like to have GMP as the only library dependency, though I do not mind using other libraries so<br />
long as they are optional. For example, one of the test programs is much easier to use if compiled with<br />
the GNU readline library, but by default compiles without it and is still functional.<br />
I dislike the C preprocessor. I like to place platform-specific code in separate files and let the build<br />
system work out which one to use. Integer constants can be defined with enum instead. I intend to<br />
minimize the number of #include statements in header files for <strong>PBC</strong>’s internal use as much as possible<br />
(they should be in the .c files instead), and later perhaps even remove those annoying #ifndef<br />
statements too. I grudgingly accept some macros for <strong>PBC</strong>’s debugging features.<br />
I liberally use nested functions, a GNU C extension. I find their expressiveness so indispensable that I’m<br />
willing to sacrifice portability for them.<br />
The GNU libc manual (http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html)<br />
states that data types ending in _t should not be used because they are reserved for future additions to C<br />
or POSIX. On the other hand, I want to stay consistent with GMP, and ending data types with _t is<br />
common practice.<br />
44