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 <[email protected]>
> >
> > > 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.
>
>
