This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: inttypes.h


Ralf Corsepius wrote:
Jeff,

I am having doubt on this patch you applied yesterday:

Index: libc/include/inttypes.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/inttypes.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- libc/include/inttypes.h     20 Sep 2005 19:25:57 -0000      1.1
+++ libc/include/inttypes.h     20 Sep 2005 21:21:51 -0000      1.2
@@ -14,6 +14,8 @@
 #define _INTTYPES_H

 #include <stdint.h>
+#define __need_wchar_t
+#include <stddef.h>

#define __STRINGIFY(a) #a

IMO, this kind patch should be applied to stdint.h instead, because
"stdint.h exports types", while "inttypes.h uses them", and because
stdint.h probably will need stddef.h to get wchar_t support, anyway.

Ralf


Actually, nothing in stdint.h implies it refers to wchar_t, only inttypes.h does. If you look at glibc's implementation you will see it does the same thing as I do - namely, it includes the wchar_t type where it is needed. The inttypes.h header has prototypes that refer to wchar_t so it has to ensure the type is defined.


Another way to look at this is that if someone wants to supply their own stdint.h, what are the chances it will have wchar_t defined there? (both Cygwin and glibc's stdint.h don't, for example).

-- Jeff J.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]