jacob navia said:
This is just meaningless, as we have discussed several times.
It suffices for the compiler to issue one "diagnostic" like
"This program may contain errors"
and that single diagnostic makes it conforming...
It's not meaningless. That's *exactly* what it means.
If you want the standard to provide more stringent requirements for
diagnostics, the best way to make that happen would be to propose new
wording for those requirements. I'm not saying that expressing
dissatisfaction with the current state of affairs is a bad thing, but
it's only the first step.
In my opinion (and yes, I know you disagree), the standard's current
wording is adequate. A conforming implementation could produce a
single diagnostic for all translation units -- but in practice none
actually do so. From what I've seen most existing compilers do
produce reasonably decent diagnostics.
If it were easy to modify the standard to require more than it does
now, I'd be all for it -- but I don't think it would be easy. And
since the purpose of such a change would be to require implementations
to do what they already do, I personally don't think it would be worth
the effort.
A set of constraints violation that must have as a consequence
that the compiler emits a diagnostic for each of them.
Ok. I wouldn't have chose the phrase "core diagnostics package" for
that idea, but I'll accept it.
Do you mean that *all* constraint violations in each translation unit
must be diagnosed, or do you propose that each of some defined subset
of constraint violations must be diagnosed? (In the latter case, if a
translation unit contains two constraint violations that aren't in the
core set, a single diagnostic would be sufficient.) If the latter,
how would you determine which constraints belong to this core set?
I'm not attacking your idea here, I'm just asking for clarification.
If you mean that a compiler must diagnose all constraint violations in
a translation unit, I think that would be difficult to specify in many
cases, let alone to implement.
Consider this, for example:
int main(void)
{
short float f;
float *p = &f;
return 0;
}
The "short float" violates the constraint of 6.7.2p2. But is
"float *p = &f;" a constraint violation or not? If f were of type
short, it would be; if f were of type float, it wouldn't be. The
compiler can't reasonably guess the programmer's intent here.
One constraint violation can, in some cases, make it difficult or
impossible to correctly interpret the code that follows it and to
detect further constraint violations. Syntax errors, of course, are
even worse.
In my opinion, compiler implementers (yourself included) are already
motivated to diagnose as many errors as possible. Requiring it in the
standard might be nice, but I honestly don't think it's necessary.
But if you can come up with proposed wording that's an improvement
over what the standard says now, I'd love to see it, and I'll be glad
to help by looking for problems in it.
look, I said explicitly that the form wasn't important!
I just re-read your article. I suggest you read-read it yourself.
You said no such thing. If I missed it, please point it out to me.
This is typical of K Thompson. Take one sentence and twist it
to give something absurd. Then asking:
Is that what you want?
And this is, unfortunately, quite typical of you. (Incidentally, most
people here call me Keith, and you're welcome to do likewise. Your
habit of calling me by my last name when you're mad at me is
annoying.)
I merely asked for clarification. My own words are rarely as clear on
the screen as they were in my head.
Obviously when I use
"return used with a void function" I mean a return expression.
That is just polemic.
No, I merely asked for clarification. I'm not a mind-reader. I
merely assumed that you meant what you said. It was not as obvious as
you seem to think it was.
This could be avoided with a standard way of annotating the compiler,
another widespread need that has been solved differently in different
compilers and cries for a solution in the standard.
GNU uses the
__attribute__(feature)
syntax, and Microsoft uses
__declspec(attribute)
syntax.
Using one of those we could just write
__declspec(notreached);
and be done with it.
This is another subject and another discussion of course,
I just note the inactivity of the committee in this
subject. Microsoft has introduced an extended syntax for
marking up the function arguments with in/out and in/out
parameters (what is a good idea). Gcc has used the
__attribute__ syntax for alignment and many other things.
If we had a standard all that could be written PORTABLY
Then by all means feel free to present a concrete proposal.
For example, consider this:
int foo(int n) {
if (n < 0) {
/* Serious error, give up */
exit(EXIT_FAILURE);
}
else {
return n + 1;
}
}
If I understand you correctly (and *please* correct me if I don't),
this would require a diagnostic because the function might terminate
without executing a return statement (and the compiler doesn't
necessarily know what exit() does). But adding
__declspec(notreached);
would inhibit the diagnostic.
Which means that code that's currently perfectly valid would become a
constraint violation. The committee, quite properly, takes a dim view
of breaking existing code.
I wouldn't mind seeing something like what you're proposing in a
future standard, but you've got to accept constructive criticism.
[snip]
Support for unprototyped functions was necessary for compatibility
with pre-ANSI compilers. The committee apparently felt that 1999 was
too soon to require prototypes for all functions, and I tend to agree
with that decision. But C99 dropped implicit function declarations,
and non-prototype declarations are obsolescent.
-- Implicit declaration of a symbol
Is there a case of this that's not already a constraint violation in
C99?
Yes, in the case of a function call. I meant the
declaration
a;
with implicit meaning
int a;
Huh? "a;" doesn't mean "int a;" in C99; implicit int was dropped,
remember? (I'm not even sure that "a;" means "int a;" in C90, but
since we're talking about possible future changes to the standard,
that's hardly relevant.) And implicit function declarations were
removed as well. See page xii in the foreword.
Is this why you've never made a clear statement that lcc-win fully
conforms to C99? If you don't understand what the standard says, how
can you say whether your compiler conforms to it?