oups include the list this time sorry for the noise Pascal. On 12 December 2011 16:00, Pascal Stumpf <pascal.stu...@cubes.de> wrote: > 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.
restrict is a C99 keyword and has no meaning (ie doesn't exist) in the C++ standard.
