all errors and warnings in C

[prasanna]

i will be very thankful if you sent all the errors and warnings regarding
to the language C

thank you

 

[Igmar Palsenberg]

i will be very thankful if you sent all the errors and warnings regarding
to the language C

Warnings and errors depend on the compiler used. The C standard only
dictates what is correct C, it doesn't care what the actual error
messages are what a compiler produces.

thank you

Igmar

 

[Mike Wahler]

i will be very thankful if you sent all the errors and warnings regarding
to the language C

The language standard requires an implementation to issue
a diagnostic message for certain language rule violations.
The actual text of such messages is not specified. I.e.
every message could be simply e.g. "ERROR!". "Warnings" are
not required at all. Most implementations do provide somewhat
meaninful warnings and errors, and each will have their own.
Consult your documentation.


-Mike

 

[Keith Thompson]

i will be very thankful if you sent all the errors and warnings regarding
to the language C

I'm afraid your question doesn't make much sense.

A particular compiler might have a list of all the error and warning
messages it can produce, but it's going to be different from the
messages another compiler can produce. Compiler vendors don't
typically provide such lists, since they're not likely to be useful.
In any case, questions about specific compilers are off-topic here.

(The number of mistakes you can make while programming in C is, of
course, unlimited.)

 

[Dan Pop]

i will be very thankful if you sent all the errors and warnings regarding
to the language C

The C standard contains the complete list of instances requiring a
compiler diagnostic. It doesn't divide compiler diagnostics into
errors and warnings and it doesn't provide any requirements WRT the
proper phrasing of these diagnostics. It also explicitly allows
implementations to produce other diagnostics than the required ones, as
long as the required ones are produced.

Furthermore, only *one* diagnostic is required for a "faulty" translation
unit, no matter how many standard violations requiring a diagnostic it
contains.

So, the minimal requirements imposed by the language are trivially met
by a compiler displaying a copyright message for each and every
translation unit processed, whether it is perfectly correct or not.

Real implementations usually do better than that, but each decides how
much better.

Dan

 

[Kenneth Brody]

The language standard requires an implementation to issue
a diagnostic message for certain language rule violations.
The actual text of such messages is not specified. I.e.
every message could be simply e.g. "ERROR!". "Warnings" are
not required at all. Most implementations do provide somewhat
meaninful warnings and errors, and each will have their own.
Consult your documentation.

Can a compiler "make up" its own warnings? Could a conforming compiler
issue a warning if the definition of main() didn't start on an odd-numbered
line, or if you used the "wrong" method of placing braces?

$ yuckycc -c foo.c
foo.c:8 Warning! Definition of main() should be on an odd-numbered line.
foo.c:10 Warning! I don't like variables named "j".
foo.c:12 Warning! Braces belong indented below the if() line.
foo.c:297 Warning! Length of source file exceeds the day of the year.

 

[Joona I Palaste]

Can a compiler "make up" its own warnings? Could a conforming compiler
issue a warning if the definition of main() didn't start on an odd-numbered
line, or if you used the "wrong" method of placing braces?

$ yuckycc -c foo.c
foo.c:8 Warning! Definition of main() should be on an odd-numbered line.
foo.c:10 Warning! I don't like variables named "j".
foo.c:12 Warning! Braces belong indented below the if() line.
foo.c:297 Warning! Length of source file exceeds the day of the year.

This is entirely allowed, as long as the compiler actually compiles the
code according to the ISO C standard. The warnings don't even have to
have anything to do with the source code. This is allowed too:

$ yuckycc -c foo.c
foo.c:1 Warning! You are too ugly to be writing C code!
foo.c:2 Warning! Your feet smell! When did you last take a bath?

 

[Eric Sosman]

Can a compiler "make up" its own warnings? Could a conforming compiler
issue a warning if the definition of main() didn't start on an odd-numbered
line, or if you used the "wrong" method of placing braces?

$ yuckycc -c foo.c
foo.c:8 Warning! Definition of main() should be on an odd-numbered line.
foo.c:10 Warning! I don't like variables named "j".
foo.c:12 Warning! Braces belong indented below the if() line.
foo.c:297 Warning! Length of source file exceeds the day of the year.

Yes, of course.

foo.c:1 Warning! Using "foo" as a file name is deprecated.
foo.c:42 Warning! This really isn't The Answer.
foo.c:56 Accolade! malloc() used without a cast.

However, if the program is correct the implementation must
accept and attempt to execute it, no matter how many warnings
or other diagnostics it has issued.

There's no straightforward technical criterion by which
one can determine whether a particular warning is superfluous
or essential: it's matter of the expected "error styles" of the
users. When the compiler draws attention to perfectly correct
C code, it may just be making useless noise -- but on the other
hand, it may be saving your butt.

switch (what) {
case 1:
x = f();
break;
case 2:
x = g();
break;
case3:
x = h();
break;
}

.... is perfectly good C, yet I for one would be glad to be warned
that `x = h();' is not reachable, or that the label `case3' is
not used.

It's a QoI ("Quality of Implementation") issue -- and "Q"
is neither one-dimensional nor even measured the same way by
all users of the compiler.

 

[Gordon Burditt]

i will be very thankful if you sent all the errors and warnings regarding

Can a compiler "make up" its own warnings?

Yes. Since warnings are not required at all, ALL warnings are "made
up". I consider this true even in spite of a "common warnings"
chapter in the (C90) standard, which does not pretend to contain actual
wordings of warning messages.

Could a conforming compiler
issue a warning if the definition of main() didn't start on an odd-numbered
line, or if you used the "wrong" method of placing braces?

$ yuckycc -c foo.c
foo.c:8 Warning! Definition of main() should be on an odd-numbered line.
foo.c:10 Warning! I don't like variables named "j".
foo.c:12 Warning! Braces belong indented below the if() line.
foo.c:297 Warning! Length of source file exceeds the day of the year.

Yes, and this is acceptable per the standard even if the warning
is a lie (e.g. main() DOES begin on an odd-numbered line). It's a
quality-of-implementation issue.

However, I believe it is not acceptable to have an infinite number
of warnings for a standards-correct program, as that amounts to
failure to compile it. I don't believe that anything in the standard
prohibits the compiler from issuing a warning *AND* deleting the source
code if it generates a correct program.

Gordon L. Burditt

 

[Mark McIntyre]

Can a compiler "make up" its own warnings? Could a conforming compiler
issue a warning if the definition of main() didn't start on an odd-numbered
line, or if you used the "wrong" method of placing braces?

Just so long as it doesn't prevent compilation of a valid programme.

$ yuckycc -c foo.c

foo.c:11 warning: I never could get the hang of thursdays.
foo.c:22 information: the Liberator is under attack.

 

[S.Tobias]

So, the minimal requirements imposed by the language are trivially met
by a compiler displaying a copyright message for each and every
translation unit processed, whether it is perfectly correct or not.

I don't see it. Footnote 8 to chapter 5.1.1.3 (Diagnostics)
says: "The intent is that an implementation should identify the
nature of, and where possible localize, each violation. [...]".
Copyright message definitely doesn't satisfy above intent.

I think even if a compiler spat out all possible diagnostic messages
on each run, it still shouldn't count as diagnostic.

 

[Richard Bos]

So, the minimal requirements imposed by the language are trivially met
by a compiler displaying a copyright message for each and every
translation unit processed, whether it is perfectly correct or not.

I don't see it. Footnote 8 to chapter 5.1.1.3 (Diagnostics)
says: "The intent is that an implementation should identify the
nature of, and where possible localize, each violation. [...]".
Copyright message definitely doesn't satisfy above intent.

Footnotes are not normative. An implementation that behaved as Dan
suggests would certainly be a bad implementation, but not a
non-conforming one.

Richard

 

[Dan Pop]

However, if the program is correct the implementation must
accept and attempt to execute it, no matter how many warnings

^^^^^^^^^^^^^^^^^^^^^^^^^

or other diagnostics it has issued.

Can I have a chapter and verse for that?

It is trivial to generate a correct C program that exceeds the translating
capabilities of any given implementation, while still staying within the
translation limits imposed by the standard.

Dan

 

[Dan Pop]

So, the minimal requirements imposed by the language are trivially met
by a compiler displaying a copyright message for each and every
translation unit processed, whether it is perfectly correct or not.

I don't see it. Footnote 8 to chapter 5.1.1.3 (Diagnostics)
says: "The intent is that an implementation should identify the
nature of, and where possible localize, each violation. [...]".
Copyright message definitely doesn't satisfy above intent.

I think even if a compiler spat out all possible diagnostic messages
on each run, it still shouldn't count as diagnostic.

Footnotes are not normative. What the normative text of the standard
actually says is:

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

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.

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.

Dan

 

[S.Tobias]

So, the minimal requirements imposed by the language are trivially met
by a compiler displaying a copyright message for each and every
translation unit processed, whether it is perfectly correct or not.

I don't see it. Footnote 8 to chapter 5.1.1.3 (Diagnostics)
says: "The intent is that an implementation should identify the
nature of, and where possible localize, each violation. [...]".

Footnotes are not normative. What the normative text of the standard
actually says is:

[snipped relevant quotes from 3.10 and 5.1.1.3]

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).

The problem for me is that 3.10 actually defines "diagnostic
message" as a term, and I have to follow its definition rather
than attach usual meaning to it; which means that I must agree to
your interpretation.

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.

So could printing an empty string, ie. printf(""), count as
diagnostic message?

 

[S.Tobias]

it is even not a message, because it does not convey
any information (if it appears on every compilation).

This is nonsense. Please drop it.

 

[Dan Pop]

So could printing an empty string, ie. printf(""), count as
diagnostic message?

Printing an empty string means not doing anything at all.

1 A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
How do you identify the fact that the implementation has printed an empty
string?

I think that the diagnostic message has to consist from at least one
printable character, so that the user can identify it.

Otherwise, I agree that an empty string contains as much useful
information as an unconditionally issued copyright message, when
interpreted as a diagnostic.

Dan

 

[S.Tobias]

Printing an empty string means not doing anything at all.

I think that the diagnostic message has to consist from at least one
printable character, so that the user can identify it.

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

I'd welcome your comment on my new take on the issue.



The Standard defines "diagnostic message" as a "subset of implementations
message output". It does not define "message" or "output" (for the
translation environment), so we're allowed to use English dictionary
definitions, so www.m-w.com tells us:

message:
1 : a communication in writing, in speech, or by signals

output:
e : the information produced by a computer

Therefore, compiler need not print anything as a diagnostic message, it
may read the message aloud (through the loudspeakers), flash a light, or
ring a bell (the compiler might actually be a wooden construction, powered
by the force of your muscles, witout any electric equipment attached).

Further, the light need not be in the visible spectrum, neither the
sound of the bell need be heard (if I close my eyes, it doesn't render
my compiler non-conforming).

Up to now we have learned, that in order for the compiler to produce a
diagnostic message, it need not do anything that is necessarily perceived
by human senses, but it must do "something" which the documentation
defines as diagnostic message.

So, when the diagnostic is required, that something might be executing
a special piece of code (presented as pseudo-code here):
[...]
if do_diagnostic
nop ; executing this line constitutes a diagnostic message
[...]
(It doesn't matter you can't normally see it; you might see this line
executed in your debugger, if you really wanted.)

Since the compiler is allowed to produce more diagnostics that necessary,
we might simplify the above to:
; start of the compiler code
nop ; executing this line constitutes a diagnostic message
[...] ; rest of the compiler code
Or let's go to the extreme:
; start of the compiler code
; executing any line of this code constitutes a diagnostic message
[...] ; rest of the compiler code

Thus we have proved, that in order to produce a diagnostic the Standard
does not actually require the compiler to do anything special, if the
compiler does something (runs a portion of code) and the docs identify
it as a diagnostic message.

Final note: The documentation cannot claim that mere running (starting)
the compiler program is a diagnostic, because the Standard requires some
activity on the part of the compiler ("implementation shall produce");
starting the compiler is performed by the user (or OS on the low level).
For the same reason the sun-rise cannot constitute a diagnostic, unless
you find a philosopher that can prove that sun-rise is caused by running
the compiler program (both are in near time-space distance, so it might
be not impossible; another possibility could be to officially include
all sun-rises as part of a translation).

 

[Keith Thompson]

Final note: The documentation cannot claim that mere running (starting)
the compiler program is a diagnostic, because the Standard requires some
activity on the part of the compiler ("implementation shall produce");
starting the compiler is performed by the user (or OS on the low level).
For the same reason the sun-rise cannot constitute a diagnostic, unless
you find a philosopher that can prove that sun-rise is caused by running
the compiler program (both are in near time-space distance, so it might
be not impossible; another possibility could be to officially include
all sun-rises as part of a translation).

The compiler could wait until the next local sunrise to produce its
output if it wants to issue a diagnostic, or produce output
immediately if it doesn't; then the sunrise could be considered a
diagnostic. (This is ambiguous if you happen to run the compiler at
sunrise, but the implementation is allowed to produce extraneous
diagnostics.)

<OT>I think you mean sed 's/[A-Z]//g'.</OT>

 

[S.Tobias]

The compiler could wait until the next local sunrise to produce its
output if it wants to issue a diagnostic, or produce output
immediately if it doesn't; then the sunrise could be considered a
diagnostic. (This is ambiguous if you happen to run the compiler at
sunrise, but the implementation is allowed to produce extraneous
diagnostics.)

I'm not sure what you mean. My intention has been that the sunrise
*is* the diagnostic message. To be quite clear (I hope this is
Standard conforming):


ReallyBig(t) C compiler documentation

[...]
The ReallyBig(t) compiler is composed of two parts: the electronic
part, which runs on your computer and does the proper source
translation; and a small part of the Solar System, namely the planet
Earth and the star Sun, which is responsible for the diagnostic
messages. The full source translation comprises two major phases:
the source processing, and the processing and output of the
diagnostic messages (you have to wait for the both to complete;
the compiler might issue additional diagnostics during a long
compilation phase). The diagnostic message is identified as the
sunrise at the location where the compiler performed or finished
the source processing. Note: User might have to wait up to 24h
for the processing of the diagnostic to complete. (User might skip
the output of the diagnostics and start another source processing
phase; then the next diagnostic messages shall apply only to the
last started translation; it has to be noted though, that this is
a serious deviation from the Standard conformance, and is available
at User's option only.)
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.
[...]

<OT>I think you mean sed 's/[A-Z]//g'.</OT>

Of course, thanks! I thought I had fixed it long ago.