14.07.2013 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!