Bug 717

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.