I chose C because:
- GMP, which PBC requires and is also modeled on, is also written in C.
- PBC is intended to be a low-level portable cryptographic library. C is the least common denominator. It should not be difficult to wrap PBC for other languages.
- Despite its drawbacks (I would appreciate operator overloading and genericity, and to a lesser extent garbage collection), I’ve found few languages I like better. To quote Rob Pike, C is the desert island language. (I also agree with his statement that OO languages conceptually provide little extra over judicious use of function pointers in C.)
With respect to indentation, I’m migrating the code to follow Google C++ Style Guide to avoid having to switch styles all the time. The code was originally written using my old style: 4-space indent with 1TBS (One True Brace Style).
I’d like to have no library dependencies (except standard C libraries), but then I’d have to write a large integer library. Furthermore, I’d have to write it in assembly, and then port it.
To avoid this, I use an existing library. I selected GMP because the library’s focus is on multiprecision arithmetic and nothing else, and it aims to be as fast as possible on many platforms. Another important factor is that GMP is released under a free license.
On the other hand, GMP is written to deal with extremely large numbers, while I mostly only need integers that are roughly between 160 and 2048 bits. It is possible a library specializing in numbers of these sizes would be better for PBC.
I’m fond of GMP’s method for eliminating the need for the
& and * operators most of the time by declaring a
typedef on arrays of size 1. I try to do the same with PBC for
consistency, though this trick does have drawbacks.
I would like to have GMP as the only library dependency, though I do not mind using other libraries so long as they are optional. For example, one of the test programs is much easier to use if compiled with the GNU readline library, but by default compiles without it and is still functional.
I dislike the C preprocessor. I like to place
platform-specific code in separate files and let the build
system work out which one to use. Integer constants can be
defined with enum instead. I intend to minimize the number of
#include statements in header
files for PBC’s internal use as much as possible (they should
be in the .c files instead), and
later perhaps even remove those annoying #ifndef statements too. I grudgingly accept
some macros for PBC’s debugging features.
I liberally use nested functions, a GNU C extension. I find their expressiveness so indispensable that I’m willing to sacrifice portability for them.
The GNU libc manual states that data types ending
in _t should not be used because
they are reserved for future additions to C or POSIX. On the
other hand, I want to stay consistent with GMP, and ending data
types with _t is common
practice.