This is the mail archive of the 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]
Other format: [Raw text]

Re: named warnings & individual warning control

DJ Delorie wrote:

I did provide an implementation way back when. I'm not saying it
was a great implementation, but it did work; it was in the tree for
less than 24 hours before Jason yanked it back out. At that time,
the policy decision was "we don't want this feature".

It's come up so many times in the past that I think whether *we* want
this feature or not is now irrelevent; enough gcc users want it to
justify it, else we're doing a disservice to the gcc user community.

I agree; this would be a useful feature, if we can figure out how to do it, and if we have the resources to maintain it. The reason I implemented it once before was because people wanted it. However, there is a real cost here: adding new messages becomes harder, and has more interface implications for users from release to release.

That's why I think that you need to get consensus on this issue before you get too committed here.

Granted, if we don't want individual control over messages, this whole
project is a lot less useful. However, we have customers who really
need this functionality, and have resorted to manually editing gcc's
sources to do what they need. I think we all agree that such a
"solution" is possibly the worst available solution.

Actually, no. Even worse is to have code that is hard to maintain in the compiler, or to make promises to our users that we can't keep.

The problem, in my mind, is that as soon as you provide the mnemonic, people will want and expect it to be stable, no matter what else you tell them.

My original post indicated that we make it clear that such mnemonics
WILL (not may) change. We can programmatically renumber them for each
release to keep people honest (IIRC Apple did something similar with
their BIOS to keep app developers from cheating) but I suspect that's

I don't think this is a problem you can solve with documentation.

In fact, I've done this exact same thing before on the exact same issue in another compiler, and had precisely this problem: lots of unhappy customers when the ids changed, even when we explicitly told them that they would.

Ok, let me propose this: Messages with numeric suffixes will be
unavailable to the user.  This is a trivial restriction we can add to
any design, which allows us to obtain the benefits (TBD or as listed
below) of a new design, plan for future policy changes (and perhaps
implement them trivially), and - for those customers who absolutely
must have such control - the ability to maintain a local patch easier.

(Or, take a clue from sendmail and add a
option ;-)

Given that, I think a new design can still provide benefits:

* The user can still control warning groups from within the code
(i.e. #pragma GCC message ignore format, #pragma GCC message error
writable-strings, etc), even if such groupings are no more flexible
than the set of -W options we currently offer.

Yes, agreed; that, I think is non-controversial functionality. Note that you could do this without a central warning catalog.

* Grouping of messages into command line options is centralized
(leading to easier auditing, machine-generated documentation,
reverse indexes, {user,target,language}-definable groups, etc).

This is probably good -- although it was also true of my patch, and some people were very much opposed to not being able to just tweak the source code.

* Logic for deciding if a standard cares about a message, for example,
can be moved out of the code (reducing code complexity there). This
may or may not be easier on the developer, but it allows for some
standards auditing reports to be automatically generated.

This is desirable -- but may not be easy; sometimes the same message might result from undefined behavior in some cases but just a warning in others. I'm not sure.

* We can provide both a terse and a verbose text for each message, and
let the user select which they desire. Or perhaps link to online
documentation relevent to each message printed. Lots of flexibility


* GCC could be told to print, for each message printed, the option(s)
which control the group(s) that message is(are) in.


* Grepping for mnemonics in the code is slightly easier than grepping
for strings, especially when it's not obvious which bits of the
strings come from the format and which come from the arguments


* We can provide a more flexible alternative to -Werror (it was
proposed to use -E* like -W*, for example, -Eformat is like -Wformat
but it's an error instead of a warning (-E alone is its old meaning


* Deferring the categorization of a message as an error, warning, or
whatnot - and thus treating them the same whenever possible - makes
us (gcc developers) think about what MUST be an error and what only
DEFAULTS to being an error.

Yes -- although given our current codebase it's very dangerous to relax errors to warnings. It's also a problem for backwards compatibility; sometimes what you could tolerate in one release is not the same as what you can tolerate in the next.

In general, I agree with your benefits list -- but I think you need to get buy-in on the idea that centralizing the message database is a good thing. For example, I think you need to get Jason to agree that he no longer objects to this -- or decide explicitly to ignore his objections. :-)

Note that you could get some of the same benefits by just adding the #pragmas for the current warning groups, and by having calls to "warning" take an optional group flag word, which you would then insert at the call sites. When warnings for that group were disabled, the calls would return immediately. I don't think there are any major user interface impliciations of that; it's a clear win. And, it doesn't have the same maintenance or methodology implications for the rest of the compiler.

I understand why that's not as atttractive from some other perspectives, but I think it should be on the table as well.

Mark Mitchell
CodeSourcery, LLC
(916) 791-8304

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