all errors and warnings in C

D

Dan Pop

In said:
AFAICT the Standard doesn't say anywhere that translation environment
messages have to be printed.

Aren't you arguing with yourself? You mentioned printf("") as a
diagnostic, not me.
I'd welcome your comment on my new take on the issue.

Messages don't have to be printed: spoken messages or Morse code
messages on the terminal's beeper or smoke messages from the computer's
power supply are all OK. What matters is that:

1. The message is generated by the implementation.

2. The message can be identified as such by the user, after reading the
implementation's conformance document.

Everything else is a QoI issue.

Dan
 
D

Daniel Haude

On 20 Jul 2004 20:30:24 GMT,
in Msg. said:
I intended to argue here that a mere copyright message is not
diagnostical; it is even not a message, because it does not convey
any information (if it appears on every compilation).

This indeed seems stupid, but it is in fact impossible for the standard
to require meaningful diagnostics. That's because "meaningful" implies
some basic understanding between the compiler and whatever (if any)
entity receiving its messages. If the standard required such
understanding, the conformity of the compiler would suddenly depend on
its user (who, for instance, might not speak the language of the locale
for which the compiler is configured).

--Daniel
 
K

kal

So, if the implementation documents that all its diagnostics have the
format:

(c) 2004 Foo & Bar Corp

it is explicitly meeting the requirements imposed by the *normative*
text of the standard.

Certainly. But as you say, ONLY if the implementation DEFINES
this message as the sole member of the DIAGNOSTIC MESSAGES set
which is a subset of the messages set. In which case this
message cannot be used for any other purposes.

I personally prefer: Un, deux trois, Voila le Roi

Even then this creates a problem with regard to 5.1.1.3 (2)
since at lease two diagnostic messages are indicated there.
Perhaps not, as undefined behaviour requires no diagnostic.

IMHO, we ought to go a little easy on the lawyerese.


5.1.1.3 Diagnostics

2 EXAMPLE An implementation shall issue a diagnostic for the
translation unit:

char i;
int i;

because in those cases where wording in this International
Standard describes the behavior for a construct as being
both a constraint error and resulting in undefined behavior,
the constraint error shall be diagnosed.
 
D

Dan Pop

In said:
Certainly. But as you say, ONLY if the implementation DEFINES
this message as the sole member of the DIAGNOSTIC MESSAGES set
which is a subset of the messages set. In which case this
message cannot be used for any other purposes.

Sez who? Where does the standard say "an *exclusive* subset"?
Even then this creates a problem with regard to 5.1.1.3 (2)
since at lease two diagnostic messages are indicated there.

NO translation unit *requires* more than ONE diagnostic:

1 A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner)...

There is no normative wording requiring one diagnostic per violation.
It wouldn't be feasible, anyway:

fangorn:~/tmp 587> cat junk.c
just a bunch
of nonsense
from the C
compiler point of view.
fangorn:~/tmp 588> gcc -ansi -pedantic junk.c
junk.c:1: error: parse error before "a"

Does this mean that lines 2, 3 and 4 are syntactically perfect? ;-)
IMHO, we ought to go a little easy on the lawyerese.

On this particular issue, it's either lawyerese or the Babel tower of
real world implementations. Why do you think the latter is more suitable
for discussion?
5.1.1.3 Diagnostics

2 EXAMPLE An implementation shall issue a diagnostic for the
translation unit:

char i;
int i;

because in those cases where wording in this International
Standard describes the behavior for a construct as being
both a constraint error and resulting in undefined behavior,
the constraint error shall be diagnosed.

Entirely irrelevant to whatever point you were trying to make. It
merely shows an example where undefined behaviour doesn't override the
requirement for ONE diagnostic (due to a constraint violation).

Dan
 
K

Keith Thompson

S.Tobias said:
I'm not sure what you mean. My intention has been that the sunrise
*is* the diagnostic message.
[...]

Yes, that's what I meant.

I see I was ambiguous in talking about the compiler's output. It
could be an object file, or it could be a copyright message that's
produced unconditionally, but now that I think about it there needn't
be any output at all. The sunrise is the diagnostic; the compiler
"produces" it by waiting until sunrise to terminate. (And the
compiler documentation asserts that the sun rises because the compiler
causes it to do so.)

[...]
Disclaimer: The ReallyBig(t) C compiler might not be Standard
conforming above the polar circles in certain seasons of the year,
or at high altitudes above the surface of the Earth.

Running in the polar regions isn't a problem, but it can take up to a
year to produce a diagnostic. In (non-polar) Low Earth Orbit, the
maximum delay can be as short as 90 minutes or so.

This is, of course, exceedingly silly (just in case nobody had noticed
that yet).
 
R

Richard Bos

Certainly. But as you say, ONLY if the implementation DEFINES
this message as the sole member of the DIAGNOSTIC MESSAGES set
which is a subset of the messages set. In which case this
message cannot be used for any other purposes.

Chapter and verse, please.

Richard
 
D

Dan Pop

In said:
#error Would you care to
#error make a small wager?
#error (See Section 6.10.5)

You're talking about a different sort of diagnostics.

But I challenge you to prove that an implementation that stops processing
the translation unit after the first #error directive is non-conforming.
Clue: 4p4.

Dan
 
K

kal

Most amusing.

Perhaps so, but I find it perplexing.
I hope you did look that up. It is a celebrated verse.
I take it you didn't actually know what you were on about,
upthread.

It would have been rude of me to have botherd you had I known
about it.
Which is not surprising, since you were wrong.

I agree with that. It is quite comforting.

<OT>
You may have noticed the hullabaloo about M. Hawkings
presentation about blackholes and information loss etc.
I know he is wrong, he knows he is wrong, most everyone
knows he is wrong. He is merely LESS wrong than he was.
</OT>

My queries were about M. Pop's assertion that the standard
requires at most ONE diagnostic and it can be anything at all.
Omitting for the present, flashing lights, and other forms of
display and confining ourselves to text output, the implication
is that any text output is sufficient to satisfy the requirements
of the standard and the content of the text output can be
the same for any and all diagnostics.

He is probably right. He usually is in these matters. But since
he is kind enough to expend some of his time and energy, I was
merely taking advantage of it to get my own understanding of the
issue clarified as much as possible.

In these matters one has to take the standard as a whole. So I
quoted a passage that deals with diagnostics about undefined
behaviour and constraint violation etc. To which M. Pop rightly
pointed out that it is irrelevant to the argument.

Quoted below are some chapters and verses. Note that 3.10 IMPLIES
the set "MESSAGE OUTPUT" of which diagnotic messages are a SUBSET.
But as M. Pop pointed out, a set IS a subset of itself.

(3=2+1 so, oddly enough, 3.10(1) is close enough to 21:11)

Note that F.7.2 implies more than one diagnostic message output
but it is only a RECOMMENDED PRACTICE and not a REQUIRED one.

3.10
1 diagnostic message
message belonging to an implementation-defined subset of the
implementation's message output

5.1.1.3 Diagnostics
1 A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as undefined
or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
2 EXAMPLE An implementation shall issue a diagnostic for the
translation unit:
char i;
int i;
because in those cases where wording in this International
Standard describes the behavior for a construct as being both
a constraint error and resulting in undefined behavior, the
constraint error shall be diagnosed.

6.4.4.2 Floating constants
Recommended practice
6 The implementation should produce a diagnostic message if a
hexadecimal constant cannot be represented exactly in its
evaluation format; the implementation should then proceed
with the translation of the program.

6.7.8 Initialization
29 ... If there had been more than six items in any of the
lists, a diagnostic message would have been issued. ...

F.7.2 Translation
Recommended practice
2 The implementation should produce a diagnostic message for
each translation-time floating-point exception, other than
‘‘inexact''; the implementation should then proceed with
the translation of the program.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,773
Messages
2,569,594
Members
45,123
Latest member
Layne6498
Top