+/* The values of SEEK_SET, SEEK_CUR and SEEK_END, used by fseek().
+ Since at least one platform (POSIX) uses the same symbols for its own "seek"
+ function, we use whatever the host defines (if it does define them).
+*/
+#define _PDCLIB_SEEK_SET 0
+#define _PDCLIB_SEEK_CUR 1
+#define _PDCLIB_SEEK_END 2
+
+/* The number of characters that can be buffered with ungetc(). The standard
+ guarantees only one (1); anything larger would make applications relying on
+ this capability dependent on implementation-defined behaviour (not good).
+*/
+#define _PDCLIB_UNGETCBUFSIZE 1
+
+/* Signals ------------------------------------------------------------------ */
+
+/* A word on signals, to the people using PDCLib in their OS projects.
+
+ The way they are defined by the C standard severely limits their usefulness,
+ to the point where a library implementation need not interface with the OS'
+ signals at all (which is what the PDCLib example implementation does).
+ (Other issues include, for example, that signal handlers are not re-entrant.)
+
+ Thus, it is strongly discouraged to try bolting on a signal handling infra-
+ structure onto <signal.h>. Since C's signal handling is so limited to begin
+ with, and code using it is pretty much non-portable anyway, it would be
+ smarter to keep <signal.h> in the barely functional state it is in, and
+ instead create a better, OS-specific API.
+
+ That being said, the below signals require to be defined to a positive int
+ value. I took what my Linux box defined them to; if you have to change them,
+ and what value to change them *to*, depends heavily on your environment and
+ what you are expecting <signal.h> to accomplish (see above).