When compiling programs that use dbus, and using the -ansi -pedantic-errors mode compilation will fail due to extra ';' and also because ISO C90 doesn't support 'long long'. I nkow long long is essential to dbus, but it would be nice if I could compile my program with -ansi -pedantic-errors (:
The "long long" can probably be fixed with __extension__ or __long or something, see "info gcc" Will take patches here as long as they don't remove capabilities. We do need to use gcc-specific features, but those are properly guarded by configure checks and alternatives will be used on non-gcc platforms.
*** Bug 2707 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The "long long" can probably be fixed with __extension__ or __long or something, > see "info gcc" couldn't you use eg int64_t from stdint.h?
Hi, when I compile kdebase with -pedantic I get: /usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h:32: error: extra ';' /usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h:54: error: extra ';' Could you please remove the trailing ';'s. Cheers, André
The semicolon problem is pretty simple (I think someone already fixed it, would have to check) int64_t isn't used for a couple reasons; one is that I don't really know how portable it is in practice (maybe it is - but I don't know), and the other is that including system headers is problematic in a library; it commits you to always including them, and in the same places, since apps can start relying on their presence. So it's an API promise that's a bit hard to keep track of. And if it turned out that stdint.h _wasn't_ portable somehow, it'd be hard to fix compatibly. glib also has a "no system headers" policy for this reason.
(In reply to comment #5) > The semicolon problem is pretty simple (I think someone already fixed it, > would have to check) Nice. > > int64_t isn't used for a couple reasons; one is that I don't really know how > portable it is in practice (maybe it is - but I don't know), and the other is > that including system headers is problematic in a library; it commits you to > always including them, and in the same places, since apps can start relying on > their presence. So it's an API promise that's a bit hard to keep track of. And > if it turned out that stdint.h _wasn't_ portable somehow, it'd be hard to fix > compatibly. glib also has a "no system headers" policy for this reason. AFAIK stdint.h isn't a system header but part of the standard C lib. Its implementation probably uses system headers and maybe its broken on some anchients systems, but it should prevent you from reinventing the wheel again and again. >
Created attachment 30466 [details] [review] Fix comment bug when compiling with '-ansi'. Fix comment so that compiling with '-ansi' works.
(In reply to comment #6) > > if it turned out that stdint.h _wasn't_ portable somehow Unfortunately, it's not completely portable. In the Autoconf manual, §5.6.1 "Portability of Headers" says: `inttypes.h' vs. `stdint.h' The C99 standard says that `inttypes.h' includes `stdint.h', so there's no need to include `stdint.h' separately in a standard environment. Some implementations have `inttypes.h' but not `stdint.h' (e.g., Solaris 7), but we don't know of any implementation that has `stdint.h' but not `inttypes.h'.
nowadays, build with '-ansi' for dbus seems impossible.
Compiling in a mode that is pedantic for the sake of being pedantic is not really something we are interested in doing, so I'm closing this NOTABUG.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.