By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,705 Members | 1,301 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,705 IT Pros & Developers. It's quick & easy.

all errors and warnings in C

P: n/a
i will be very thankful if you sent all the errors and warnings regarding
to the language C

thank you
Nov 14 '05 #1
Share this Question
Share on Google+
30 Replies


P: n/a
prasanna wrote:
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
Nov 14 '05 #2

P: n/a
"prasanna" <sv**********@indiatimes.com> wrote in message
news:11******************************@localhost.ta lkaboutprogramming.com...
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
Nov 14 '05 #3

P: n/a
"prasanna" <sv**********@indiatimes.com> writes:
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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #4

P: n/a
In <11******************************@localhost.talkab outprogramming.com> "prasanna" <sv**********@indiatimes.com> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #5

P: n/a
Mike Wahler wrote:

"prasanna" <sv**********@indiatimes.com> wrote in message
news:11******************************@localhost.ta lkaboutprogramming.com...
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.


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.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Nov 14 '05 #6

P: n/a
Kenneth Brody <ke******@spamcop.net> scribbled the following:
Mike Wahler wrote:
"prasanna" <sv**********@indiatimes.com> wrote in message
news:11******************************@localhost.ta lkaboutprogramming.com...
> 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.

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?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante
Nov 14 '05 #7

P: n/a
Kenneth Brody wrote:
Mike Wahler wrote:
"prasanna" <sv**********@indiatimes.com> wrote in message
news:11******************************@localhost. talkaboutprogramming.com...
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.

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.

--
Er*********@sun.com

Nov 14 '05 #8

P: n/a
>> > 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.


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
Nov 14 '05 #9

P: n/a
On Mon, 19 Jul 2004 11:12:02 -0400, in comp.lang.c , Kenneth Brody
<ke******@spamcop.net> wrote:
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.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #10

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
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.

--
Stan Tobias
sed '/[A-Z]//g' to email
Nov 14 '05 #11

P: n/a
"S.Tobias" <sN*******@amu.edu.pl> wrote:
Dan Pop <Da*****@cern.ch> wrote:
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
Nov 14 '05 #12

P: n/a
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Dan Pop <Da*****@cern.ch> wrote:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #13

P: n/a
In <40**************@sun.com> Eric Sosman <Er*********@sun.com> writes:
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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #14

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Dan Pop <Da*****@cern.ch> wrote:
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?

--
Stan Tobias
sed '/[A-Z]//g' to email
Nov 14 '05 #15

P: n/a
I wrote:
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.

--
Stan Tobias
sed '/[A-Z]//g' to email
Nov 14 '05 #16

P: n/a
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #17

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
So could printing an empty string, ie. printf(""), count as
diagnostic message?

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

--
Stan Tobias
sed '/[A-Z]//g' to email
Nov 14 '05 #18

P: n/a
"S.Tobias" <sN*******@amu.edu.pl> writes:
[...]
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.)
--
Stan Tobias
sed '/[A-Z]//g' to email


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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #19

P: n/a
Keith Thompson <ks***@mib.org> wrote:
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.
--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #20

P: n/a
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Dan Pop <Da*****@cern.ch> wrote:
In <2m************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
>So could printing an empty string, ie. printf(""), count as
>diagnostic message?

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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #21

P: n/a
On 20 Jul 2004 20:30:24 GMT,
S.Tobias <sN*******@amu.edu.pl> wrote
in Msg. <2m************@uni-berlin.de>
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

--
"With me is nothing wrong! And with you?" (from r.a.m.p)
Nov 14 '05 #22

P: n/a
kal
Da*****@cern.ch (Dan Pop) wrote in message news:<cd**********@sunnews.cern.ch>...
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.
Nov 14 '05 #23

P: n/a
In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<cd**********@sunnews.cern.ch>...
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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #24

P: n/a
Dan Pop wrote:

NO translation unit *requires* more than ONE diagnostic:


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

--
Er*********@sun.com

Nov 14 '05 #25

P: n/a
"S.Tobias" <sN*******@amu.edu.pl> writes:
Keith Thompson <ks***@mib.org> wrote:
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.

[...]

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #26

P: n/a
k_*****@yahoo.com (kal) wrote:
Da*****@cern.ch (Dan Pop) wrote in message news:<cd**********@sunnews.cern.ch>...
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.


Chapter and verse, please.

Richard
Nov 14 '05 #27

P: n/a
In <40**************@sun.com> Eric Sosman <Er*********@sun.com> writes:
Dan Pop wrote:

NO translation unit *requires* more than ONE diagnostic:


#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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #28

P: n/a
kal
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
Chapter and verse, please.


John 21:11
Nov 14 '05 #29

P: n/a
k_*****@yahoo.com (kal) wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
Chapter and verse, please.


John 21:11


Most amusing. I take it you didn't actually know what you were on about,
upthread. Which is not surprising, since you were wrong.

Richard
Nov 14 '05 #30

P: n/a
kal
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<41****************@news.individual.net>...
k_*****@yahoo.com (kal) wrote:
John 21:11
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.
Nov 14 '05 #31

This discussion thread is closed

Replies have been disabled for this discussion.