This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFC: should we use -Werror? (& sample patch to do it)


In article <20010905123316.C386@codesourcery.com> you write:
>On Wed, Sep 05, 2001 at 03:09:04PM -0400, Kaveh R. Ghazi wrote:
>>  > 
>>  > Not true.  -Werror turns _all_ warnings into errors.
>>  > zw

>> Hmm, I tested it in 3.1 and 2.95.3 and you're right.  Well, that
>> certainly puts a monkey wrench into my plan.

>> Since these are intractable as you say, what if we applied the
>> __extension__ keyword to these strings?  Since they are from -pedantic
>> that would eliminate the warning, and thus the hard error when using
>> -Werror, right?

>No, the error issues from the tokenizer, which doesn't know anything
>about __extension__, nor should it (it would have to understand the
>expression grammar then).

The technical issue is irrelevant.

It shouldn't be hard to change the tokenizer. Okay, it doesn't have
to understand about extension, but it can insert tokens in the chain
if the string is too long, or if it has any further properties, so
that later stages, that know more about the whole thing semantics,
could decide to process it as an error.
e.g., you could rewrite "string..." as "string..." __attribute((_toolong__))
and have the further stages decide what they want to do with toolong or
something. Then they would see it together with a possible __extension__.

(Works that way thanks to ansi string concatenation)

Of course, your other points are valid.


But please, you already tried to enforce your views once by saying it
was impossible to do such and such a thing technically.

Which is clearly not true.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]