X-Git-Url: https://pd.if.org/git/?a=blobdiff_plain;f=platform%2Fexample_64%2Finternals%2F_PDCLIB_config.h;h=ba3de27e9483dbfe8eb5e7f4e71323f8d703b453;hb=01c88bc38e78e9b2c47917b85b9b497187946e3c;hp=81fdb09b4d4f4ae929be6abe6a0cdee61466a7f3;hpb=5bcc00c1b85feff1996e3f34a1a9ebf3b624161e;p=pdclib

diff --git a/platform/example_64/internals/_PDCLIB_config.h b/platform/example_64/internals/_PDCLIB_config.h
index 81fdb09..ba3de27 100644
--- a/platform/example_64/internals/_PDCLIB_config.h
+++ b/platform/example_64/internals/_PDCLIB_config.h
@@ -92,6 +92,8 @@ struct _PDCLIB_lldiv_t
 /* SHRT, INT, LONG, or LLONG (telling which values to use for the *_MIN and   */
 /* *_MAX limits); the lowercase define either short, int, long, or long long  */
 /* (telling the actual type to use).                                          */
+/* The third define is the length modifier used for the type in printf() and  */
+/* scanf() functions (used in <inttypes.h>).                                  */
 /* If you require a non-standard datatype to define the "usually fastest"     */
 /* types, PDCLib as-is doesn't support that. Please contact the author with   */
 /* details on your platform in that case, so support can be added.            */
@@ -99,15 +101,19 @@ struct _PDCLIB_lldiv_t
 
 #define _PDCLIB_FAST8 INT
 #define _PDCLIB_fast8 int
+#define _PDCLIB_FAST8_CONV
 
 #define _PDCLIB_FAST16 INT
 #define _PDCLIB_fast16 int
+#define _PDCLIB_FAST16_CONV
 
 #define _PDCLIB_FAST32 INT
 #define _PDCLIB_fast32 int
+#define _PDCLIB_FAST32_CONV
 
 #define _PDCLIB_FAST64 LONG
 #define _PDCLIB_fast64 long
+#define _PDCLIB_FAST64_CONV l
 
 /* -------------------------------------------------------------------------- */
 /* What follows are a couple of "special" typedefs and their limits. Again,   */
@@ -118,6 +124,7 @@ struct _PDCLIB_lldiv_t
 /* The result type of substracting two pointers */
 #define _PDCLIB_ptrdiff long
 #define _PDCLIB_PTRDIFF LONG
+#define _PDCLIB_PTR_CONV l
 
 /* An integer type that can be accessed as atomic entity (think asynchronous
    interrupts). The type itself is not defined in a freestanding environment,
@@ -141,10 +148,20 @@ struct _PDCLIB_lldiv_t
 
 /* Largest supported integer type. Implementation note: see _PDCLIB_atomax(). */
 #define _PDCLIB_intmax long long int
-#define _PDCLIB_INTMAX LLINT
+#define _PDCLIB_INTMAX LLONG
+#define _PDCLIB_MAX_CONV ll
 /* You are also required to state the literal suffix for the intmax type      */
 #define _PDCLIB_INTMAX_LITERAL ll
 
+/* <inttypes.h> defines imaxdiv(), which is equivalent to the div() function  */
+/* family (see further above) with intmax_t as basis.                         */
+
+struct _PDCLIB_imaxdiv_t
+{
+    _PDCLIB_intmax quot;
+    _PDCLIB_intmax rem;
+};
+
 /* -------------------------------------------------------------------------- */
 /* Floating Point                                                             */
 /* -------------------------------------------------------------------------- */
@@ -242,8 +259,8 @@ typedef int _PDCLIB_fd_t;
 /* Length of the longest filename the implementation guarantees to support. */
 #define _PDCLIB_FILENAME_MAX 128
 
-/* Buffer size for tmpnam(). */
-#define _PDCLIB_L_tmpnam 100
+/* Maximum length of filenames generated by tmpnam(). (See tmpfile.c.) */
+#define _PDCLIB_L_tmpnam 46
 
 /* Number of distinct file names that can be generated by tmpnam(). */
 #define _PDCLIB_TMP_MAX 50
@@ -262,3 +279,38 @@ typedef int _PDCLIB_fd_t;
 */
 #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).
+*/
+#define _PDCLIB_SIGABRT 6
+#define _PDCLIB_SIGFPE  8
+#define _PDCLIB_SIGILL  4
+#define _PDCLIB_SIGINT  2
+#define _PDCLIB_SIGSEGV 11
+#define _PDCLIB_SIGTERM 15
+
+/* The following should be defined to pointer values that could NEVER point to
+   a valid function. (They are used as special arguments to signal().) Again, I
+   took the values of my Linux box, which should be as good as any other value.
+*/
+#define _PDCLIB_SIG_DFL (void (*)( int ))0
+#define _PDCLIB_SIG_ERR (void (*)( int ))-1
+#define _PDCLIB_SIG_IGN (void (*)( int ))1
+