Re: condition true or false? -> (-1 < sizeof("test"))

[Eric Sosman]

[Follow-ups set to comp.std.c in view of thread drift.]

On 5/20/2012 12:16 AM, Richard Damon wrote:
> On 5/19/12 4:49 PM, Eric Sosman wrote:
>> On 5/19/2012 1:52 PM, Richard Damon wrote:
>>> On 5/18/12 8:24 AM, James Kuyper wrote:
>>>> The language has not been set in stone; C2011 made a lot of changes.
>>>> However, this is a very fundamental feature of the language. The
>>>> standard already allows a warning for such code; if your compiler
>>>> doesn't provide one, complain to the compiler vendor. The C standard
>>>> could mandate a diagnostic only at the cost of rendering the behavior
>>>> undefined if the code is compiled and executed despite generation of
>>>> that diagnostic. Such a change would break a LOT of code, and would
>>>> therefore be unacceptable.
>>>
>>> The language could define another "level" of messages besides just a
>>> single type of "diagnostic". There are several things now in the
>>> language which if the standard had language to allow it to require the
>>> emitting of a "warning" (vs an "error") could help programmers. In many
>>> cases "good" compilers already implement them. One key is that the
>>> implementation should need to define how to distinguish a "warning"
>>> diagnostic from an "error" diagnostic, and allow for possible other
>>> levels of messages (like "informational") which the standard doesn't
>>> define/mandate.
>>>
>>> Programs that created an "error" would have undefined behavior if
>>> executed (if that was even possible), while programs which only
>>> generated "warnings" should be able to be executed.
>>
>> Doesn't this suggestion lead to four types of diagnostics?
>>
>> 1) "Errors" whose issuance is required by the Standard, and
>> which are required to produce translation failure,
>>
>> 2) "Errors" whose issuance is required by the Standard, and
>> which are allowed (but not required) to produce translation
>> failure,
>>
>> 3) "Warnings" whose issuance is required by the Standard, and
>> which are not allowed to produce translation failure, and
>>
>> 4) "Informational messages" whose issuance is entirely optional
>> (the Standard might not even mention them), and which are not
>> allowed to cause translation failure.
>>
>> We already have [1] (one instance), [2] (many instances), and [4]
>> (an open-ended set); the new feature of your proposal is [3]. Are
>> you convinced [3] is the proper province of a language Standard?
>> Even if "yes," I think it would be hard to get universal agreement
>> on what particular diagnostics should be promoted from [4] to [3].
>> Note, for example, that some compilers can be told to suppress
>> specific diagnostics; this shows that the line between [3] and [4]
>> is indistinct and situational, not easily drawn by a Committee many
>> miles and years removed from a particular slice of code.
>>
>> The business of a compiler is to compile if it can and to tell
>> you potentially useful things it discovers in the process, but
>> setting policy about the use of its outputs seems to me outside its
>> proper sphere. There's a natural tendency to dump extra work onto
>> the compiler, simply because it's always "there" and in plain sight;
>> people might fail to run lint but they can't avoid the compiler.
>> But if you've got a people problem you should talk with the problem
>> people, not with ISO/IEC!
>>
>
> The reason to want to have a warning class of diagnostics in my mind
> would be most useful to allow more feature that clutter the language to
> depreciated status. For example, a rule that a warning shall be
> generated for any program that uses trigraphs, unless the first use of
> them is the sequence ??= or an option has been provided to the
> translator signifying that trigraphs are expected.

A "shall" that defers to a compiler option seems a pretty weak
requirement.

> As for your grouping of messages, I would NOT advice the standard
> distinguishing between 1 and 2 the way you have, if anything the
> difference should be on if the implementations HAS generated a
> translation result (not just on if it was allowed to), with the
> disclaimer that any use of such a result is undefined behavior.

The distinction isn't mine; it's C-as-it-stands, today. The
lone [1] is the diagnostic generated by #error, which (as of C99)
requires the compiler to reject the code. The [2] category covers
all other diagnostics required by the Standard (in C90, even #error
is a [2]), because the compiler is allowed to overlook the problem
and press onward. If it does so the behavior is undefined, with the
usual proviso that an implementation is free to define behaviors for
situations the Standard leaves undefined.

> I would agree that requiring a warning diagnostic for a signed/unsigned
> comparison operation is probably farther than should be required by the
> standard, and many of the warnings that come out of current compilers
> are beyond what should be expected out of a "basic but conforming" C
> compiler.

The phrase "quality of implementation" was used a lot when the
original ANSI Standard was new and people were getting used to it, but
it doesn't crop up as much nowadays. It seems to me a Standard does
well to steer clear of requiring a particular level of QoI -- or even
of suggesting one (look at how many people treated the Standard's
rand() example as prescriptive rather than illustrative). Besides,
I think the debate would become very politicized very quickly: If a
Committee tried to require a behavior that Compiler X exhibits but
Compiler Y does not, the decision might well be driven not by the
merits of the behaviors, but by the clout of the X and Y vendors.
Also, notions of "good practice" evolve more rapidly than Standards
can; we could easily wind up codifying what's already deprecated!

The users will "vote with their feet" in any case; the Standard
should stay out of the way and let the implementors do their own best
to attract foot traffic.

--
Eric Sosman
eso...@ieee-dot-org.invalid