-pedantic anyone?

August 23, 2008

Everyone knows that C++ plays nicely with C, until you engage with somehow stricter validation from the compiler. After that, you are on your own...

During my recent work on emountd (new EDE mount/unmount notify daemon with HAL support), I was surprised to learn that I'm not able to compile program which uses libhal with -pedantic flag.

I got this:

...found 95 target(s)...
...updating 2 target(s)...
C++ emountd.o
/usr/include/hal/libhal-storage.h:283: error: comma at end of enumerator list
cc -c -o emountd.o -Wno-long-long -Wall -pedantic -g3 -D_DEBUG -I.. -I/opt/ede/include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I. emountd.cpp
C++ emountd.o ...
...skipped emountd for lack of
...failed updating 1 target(s)...
...skipped 1

At first I thought compiler went nuts after 5 hour compile/recompile torture; to be honest, I get used to errors like this in my code, but in code which lives under /usr/, that is completely different thing.

Quick peek in libhal-storage.h, revealed this:

typedef enum {
  // ...
} LibHalVolumeDiscType;

See that last LIBHAL_VOLUME_DISC_TYPE_MO and comma at the end?

Well, both C and C++ standards doesn't allow that and -pedantic flag is here to reminds that. Set aside syntax check enforcement, long long type, heavily used in DBus, is not supported by C++ either.

Possible solutions for this is to either forget on -pedantic or to add -Wno-long-long, where warnings and errors about non standard long long will be inhibited. Since I'm much more fond of -pedantic, I took second approach.

EDIT: just checked the code for recent libhal version and seems that comma issue is fixed, so I'll have to think how to mitigate -pedantic flag for 0.5.9 version of libhal. Maybe with autoconf.