On Mon, 12 Dec 2011 14:41:45 +0100 (CET), Mark Kettenis wrote: > > Date: Sun, 11 Dec 2011 19:18:40 +0100 > > From: Pascal Stumpf <pascal.stu...@cubes.de> > > > > > I still think this should be investigated deeper. Matthew did a bit > > > of digging jusdging from: > > > > > > http://marc.info/?l=openbsd-ports&m=129783295016631&w=2 > > > > > > That raises the question what difference between the prototypes makes > > > clang++ barf. If it is only thye missing restrict qualifiers, we > > > should add those to our prototypes. > > > > > > As far as I can tell, the #defines that get removed by the diff do > > > serve a purpose. Without them, compiling > > > > > > #include <cstdio> > > > > > > with > > > > > > g++ -D_POSIX_C_SOURCE=199309 > > > > > > will fail. > > > > > > > > > > Hmm, okay. Adding __restrict to the prototypes in stdio.h and > > s/restrict/__restrict/g in cstdio gets rid of some errors, but not all > > of them. So there still seems to be some difference it doesn't like, > > but apparently, I'm totally blind as to which one. > > The s/restrict/__restrict/g in cstdio shouldn't be necessary.
Apparently, clang++ interprets "restrict" as parameter name, i.e.: attr.cc:1:50: error: redefinition of parameter 'restrict' extern "C" int foo(const char * restrict, char * restrict, ...) ^ attr.cc:1:33: note: previous declaration is here extern "C" int foo(const char * restrict, char * restrict, ...) ^ This might indeed be a bug, but I'd have to read the C++ standard to be sure. In pure C, clang doesn't complain. > The remaining conflict could be due to the __attribute__ stuff. > That'd be unfortunate, and I'd say that'd be a bug in clang++. It'd > be nice if you could check that. Easiest way would probably be to compile > a simple bit of test code like: > > extern "C" int foo(const char *, ...) __attribute__((__format__(printf, 1, 2) > ); > extern "C" int (foo)(const char *, ...); > > namespace bar { > using ::foo; > } > > and see if clang++ warns about that. Nope, it doesn't. > If clang++ really is stumbling over the __attribute__ stuff, perhaps > the right thing to do would be to remove the XXX_CHECK defines, but > leave the XXX_DYNAMIC defines. That'd still prevent the g++ failure I > mentioned above. > >