> Date: Mon, 9 Jan 2006 14:30:03 -0500 > From: DJ Delorie <[EMAIL PROTECTED]>
> > . Next, if it would not be rejected on the "we don't want to have such > > functionality" basis, then the question becomes one of what should the > > interface look like? Some possibilities include: > > > > #pragma GCC command-line -Wprecision-mismatch > > > > unilaterally set -Wprecision-mismatch > > I was planning on proposing something like: > > #pragma GCC diagnostic [warning|error|ignore] -Wprecision-mismatch > > The diagnostic machinery already has support for some of this, I had > hoped to find time to make it fine-grained, allowing you to override > the KIND of each warning, and thus override -Werror on a > per-warning-type basis. > > I had planned on forcing the user to place these pragmas before the > first function definition, otherwise it becomes difficult to track > when various warnings are in force. The *BULK* of our files with individual compilation switches only have switches for warnings or for profiling. I'd be leary of any attempt (e.g. changing code profiling options) to change code generation in the middle of a function. Our intended use (if we implement it) would be to use the pragma only prior to the start of code -- only comments, whitespace, and preprocessor directives permitted prior to the pragma. So, I'd be comfortable with such a restriction long term for code generation and related options and short term for warnings. Longer term, I'd like to be able to control warnings on a line by line basis. The ability to say "I've examined this expression / line / block / whatever of code and I'm happy with it with-regard-to warning XYZ, please be quiet" would be very valuable. Based on Gaby's comments, it sounds like fine-grained control would be a much bigger project. David -- David Taylor [EMAIL PROTECTED]
