Re: new fails on gcc 3.4, i686-unknown-openbsd3.1

[Marc Espie <espie at nerim dot net>]

On Sat, Dec 28, 2002 at 03:42:51PM -0200, Alexandre Oliva wrote:
> On Dec 28, 2002, Andrew Pinski <pinskia@physics.uc.edu> wrote:
> 
> > #define __END_DECLS     };
> 
> > Note the semicolon after }, that is what is causing it.
> 
> Looks like a job for fixheaders...  They headers are obviously in
> error.

Not a job for fixheaders. We have control over our headers, and we
fix them as needed, when such issues are discovered.

Note that the problem here is that no-one found out this was a problem
until recently.

In fact, if I had looked more closely at FreeBSD, I would have fixed
this ages ago, since Tendra C++ reported this as incorrect back in 1998.

More generally, whenever you find a problem with OpenBSD's headers, it's
hundreds of times simpler to just fix it on our side.

I'm sick of parsers that generate parsers that generate files (and
basically take forever to fix when they do the wrong thing, because
this is yet another language you have to understand).

I understand where fixheaders come from, and I understand how useful it
is for unresponsive vendors.

But, as far as OpenBSD is concerned, we would be much, much happier with
a check-headers script that diagnoses issues, so that we can fix them
once and for all, and *specifically*, not only for gcc, but for any
compiler that happens to come around. This looks to me to be a much nicer,
more well-rounded approach (of course, it means that gcc extensions are out
of the question, or should be properly protected, but this makes a lot
of engineering sense).
> That said, it would be nice if the new parser would accept such
> gratuitous constructs, even if they're not legal C++.  Even though,
> grammatically, they seem to be acceptable:
Nope, bad idea.  At least, don't accept this for our sake. We will fix
this. It's a very simple mistake. It's much easier to fix than say, std::
conformance.