Subject: Re: Fix for PR#23300 (cpp and -Wtraditional)
To: Christos Zoulas <christos@zoulas.com>
From: James Chacon <jmc@NetBSD.org>
List: tech-toolchain
Date: 12/15/2003 17:02:37
On Mon, Dec 15, 2003 at 10:42:41PM +0000, Christos Zoulas wrote:
> In article <20031215221417.GA17970@netbsd.org>,
> James Chacon <jmc@netbsd.org> wrote:
> >I tend to agree with the logic in the PR as #error was used before C89 as
> >a way to stop the pre-processor even though it wasn't a valid token. Doing
> >what gcc suggests gives you the opposite behavior which probably isn't
> >expected. Therefore #error should probably be excluded from this warning.
> >
> >Anyone have a problem with the attached patch?
> 
> Yes, this is a slippery slope. What are you planning to do with the #elif
> warning for example?

#error is a historical odditity though as to what's valid vs expected. 
Traditional cpp implementations say "#error isn't a valid token so error out"
and that's exactly what people used it for. All standardizing did there was 
make it part of the spec vs undefined localized behavior (which under the
implementations I've used error'd out as expected).

For the rest the warning should remain the same as #elif would (under 
traditional auspices) error out. Therefore it needs the leading whitespace
to work/not error on traditional. Doing that to #error changes the behaviour
returned to the programmer by 180 degrees which is going to be highly
unexepected.

Granted this is no different than using #foobar as a way to error out but
#error is exactly what was used traditionally and then grew into C89.

James