Connecting Tech Pros Worldwide Forums | Help | Site Map

Diagnostics (continued)

jacob navia
Guest
 
Posts: n/a
#1: Jul 16 '08
Consider this nice C program:

short long n;
signed unsigned b;
const long const long a;
unsigned double w;
signed float k;
short double q;
unsigned long double z;

I was astonished that my dear lcc-win very bad diagnostic messages
wrote for those errors.

After correcting that, I passed this code through MSVC and it
wrote a correct diagnostic for all of those errors... excepting
the last.

unsigned long double is legal?

I have serious doubts.

Besides, MSVC emitted just a warning for repeated qualifiers like
"const long const long"... Isn't that an error?

gcc wrote correct diagnostics for all of them, and all were errors,
not warnings.

PellesC missed "const long const long" completely, but the errors
were as I had it: just "Invalid type specification" instead of a
more specific error.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Keith Thompson
Guest
 
Posts: n/a
#2: Jul 16 '08

re: Diagnostics (continued)


jacob navia <jacob@nospam.comwrites:
Quote:
Consider this nice C program:
>
short long n;
signed unsigned b;
const long const long a;
unsigned double w;
signed float k;
short double q;
unsigned long double z;
>
I was astonished that my dear lcc-win very bad diagnostic messages
wrote for those errors.
>
After correcting that, I passed this code through MSVC and it
wrote a correct diagnostic for all of those errors... excepting
the last.
>
unsigned long double is legal?
>
I have serious doubts.
No, ``unsigned long double'' is a constraint violation, as you can
verify by re-reading C99 6.7.2, Type specifiers.
Quote:
Besides, MSVC emitted just a warning for repeated qualifiers like
"const long const long"... Isn't that an error?
No, type *specifiers* may not be repeated (other than "long long" and
variations), but type *qualifiers* such as "const" may be repeated, so
"const long const long" is equivalent to "const long long". (It's
ugly, though, so a warning seems appropriate, though it's not
required.)

C99 6.7.3p4:

If the same qualifier appears more than once in the same
_specifier-qualifier-list_, either directly or via one or more
typedefs, the behavior is the same as if it appeared only once.

The idea, I think, is that if you have a typedef for "const int", you
can still apply "const" to the typedef:

typedef const int c_int;
const c_int x = 42;

(IMHO "const" belongs on the object declaration, not buried in a
typedef, but the language allows it.)

In any case, as you know, the standard doesn't distinguish between
errors and warnings. A warning that doesn't cause translation to fail
can still be a valid "diagnostic message" as required by the standard.
Quote:
gcc wrote correct diagnostics for all of them, and all were errors,
not warnings.
Ok, but many of gcc's required diagnostic are warnings.
Quote:
PellesC missed "const long const long" completely,
Probably because it's valid.
Quote:
but the errors
were as I had it: just "Invalid type specification" instead of a
more specific error.
I don't feel strongly that a more specific error message is necessary,
but that's up to you.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Heathfield
Guest
 
Posts: n/a
#3: Jul 16 '08

re: Diagnostics (continued)


Keith Thompson said:
Quote:
jacob navia <jacob@nospam.comwrites:
<snip>
Quote:
>
Quote:
>Besides, MSVC emitted just a warning for repeated qualifiers like
>"const long const long"... Isn't that an error?
>
No, type *specifiers* may not be repeated (other than "long long" and
variations), but type *qualifiers* such as "const" may be repeated, so
"const long const long" is equivalent to "const long long". (It's
ugly, though, so a warning seems appropriate, though it's not
required.)
>
C99 6.7.3p4:
>
If the same qualifier appears more than once in the same
_specifier-qualifier-list_, either directly or via one or more
typedefs, the behavior is the same as if it appeared only once.
It is perhaps worth noting that this is a change from C90, in which
repeating a type-qualifier is a constraint violation:

"The same type qualifier shall not appear more than once in the same
specifier list or qualifier list, either directly or via one or more
typedef s."

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Keith Thompson
Guest
 
Posts: n/a
#4: Jul 16 '08

re: Diagnostics (continued)


Richard Heathfield <rjh@see.sig.invalidwrites:
Quote:
jacob navia said:
[...]
Quote:
Quote:
>Besides, MSVC emitted just a warning for repeated qualifiers like
>"const long const long"... Isn't that an error?
>
It's a constraint violation, requiring a diagnostic message. It appears
that in this case MSVC /does/ issue a diagnostic message, so that's fine.
As discussed elsethread, it's a constraint violation in C90 but not in
C99. (I seem to recall that MSVC doesn't support, or claim to
support, C99.) Either way, the warning means they're ok. At least,
it *probably* does; see below.
Quote:
Quote:
>gcc wrote correct diagnostics for all of them, and all were errors,
>not warnings.
>
The Standard makes no distinction. The Standard uses the term "diagnostic
messages". Errors and warnings are effectively mere vernacular terms.
>
Quote:
>PellesC missed "const long const long" completely, but the errors
>were as I had it: just "Invalid type specification" instead of a
>more specific error.
>
As long as a diagnostic message is produced, that's not a conformance
problem.
To digress a bit from the original question ...

C99 defines a "diagnostic message" as a "message belonging to an
implementation-defined subset of the implementation's message output".

C99 5.1.1.3 says:

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.

with a (non-normative) footnote:

The intent is that an implementation should identify the nature
of, and where possible localize, each violation. Of course, an
implementation is free to produce any number of diagnostics as
long as a valid program is still correctly translated. It may also
successfully translate an invalid program.

What hadn't fully sunk in until now is that "diagnostic messages" are
a *subset* of the implementation's message output, and the
implementation is required to document which messages are diagnostic.

Very strictly speaking, a message that says "Constraint violation on
line 42" isn't sufficient if the implementation's documentation
doesn't say that that's a "diagnostic message".

More realistically, an implementation could say in its documentation
that warnings (perhaps messages that start with "warning: ") don't
count as "diagnostic messages" within the meaning of the standard.
The intent would be that all syntax errors and constraint violations
produce actual error messages, not mere warnings. (<OT>gcc obviously
has no such policy.</OT>)

In other words, the standard doesn't distinguish between warnings and
error messages, but an implementation may do so in such a way that the
distinction is significant.

If such an implementation, in response to this:
const int const x = 42;
prints this:
warning: redundant "const" qualifier
then this would be a conformance failure for C90 (but not for C99,
which allows the redundant "const" qualifier).

I don't know what how actual implementations define "diagnostic
messages".

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Joachim Schmitz
Guest
 
Posts: n/a
#5: Jul 16 '08

re: Diagnostics (continued)


Richard Heathfield wrote:
<snip>
Quote:
unsigned long double is not in the list. MSVC6 does indeed fail to
diagnose it (which I haven't checked), so that's a conformance
violation. Good spot. If the problem exists in their latest release
too, you should consider raising a bug report, and let's hope that
Microsoft treats you better than the lcc-win32 guy treats people who
report bugs to him.
To be fair: Jacob fixes these bugs way quicker than Microsoft. 'treat' here
comes in 2 flavours, fixing bugs in a timely fashion and attitude towards
(potential) customers and users. Mircrosoft might be better at the later,
Jacob is much better at the former.

Just for the record: MSVC 8.0 AKA Visual Studio 2005 still has that bug.

Bye, Jojo


santosh
Guest
 
Posts: n/a
#6: Jul 16 '08

re: Diagnostics (continued)


Joachim Schmitz wrote:
Quote:
Richard Heathfield wrote:
<snip>
Quote:
>unsigned long double is not in the list. MSVC6 does indeed fail to
>diagnose it (which I haven't checked), so that's a conformance
>violation. Good spot. If the problem exists in their latest release
>too, you should consider raising a bug report, and let's hope that
>Microsoft treats you better than the lcc-win32 guy treats people who
>report bugs to him.
>
To be fair: Jacob fixes these bugs way quicker than Microsoft. 'treat'
here comes in 2 flavours, fixing bugs in a timely fashion and attitude
towards (potential) customers and users. Mircrosoft might be better at
the later, Jacob is much better at the former.
>
Just for the record: MSVC 8.0 AKA Visual Studio 2005 still has that
bug.
Perhaps that's because no one has noticed it yet?

Frankly such bugs won't be uncovered by routine programming or testing.
You either need a pretty thorough regression test or have some
like "new to c" work on it. :-)

Ben Bacarisse
Guest
 
Posts: n/a
#7: Jul 16 '08

re: Diagnostics (continued)


Richard Heathfield <rjh@see.sig.invalidwrites:
Quote:
jacob navia said:
<snip>
Quote:
Quote:
>Besides, MSVC emitted just a warning for repeated qualifiers like
>"const long const long"... Isn't that an error?
>
It's a constraint violation, requiring a diagnostic message. It appears
that in this case MSVC /does/ issue a diagnostic message, so that's
fine.
Just to clear this up a bit... It is a constraint violation in C90
(for two reasons) but it is not one in C99. Firstly, because long
long is a permitted type in C99 and secondly the specific constraint
about the same type qualifier appearing more than once had been
removed.

Of course, a compiler may warn about whatever it likes, but MSVC is
not a C99 compiler so a diagnostic (any diagnostic!) is required.

--
Ben.
Ben Bacarisse
Guest
 
Posts: n/a
#8: Jul 16 '08

re: Diagnostics (continued)


Ben Bacarisse <ben.usenet@bsb.me.ukwrites:
Quote:
Richard Heathfield <rjh@see.sig.invalidwrites:
>
Quote:
>jacob navia said:
<snip>
Quote:
Quote:
>>"const long const long"... Isn't that an error?
>>
>It's a constraint violation, requiring a diagnostic message.
>>
Just to clear this up a bit... It is a constraint violation in C90
(for two reasons) but it is not one in C99.
<snip>

And if I'd finished reading the thread, I'd have seen it was well and
truly cleared up already. Sorry for the noise.

--
Ben.
Iman S. H. Suyoto
Guest
 
Posts: n/a
#9: Jul 16 '08

re: Diagnostics (continued)


Joachim Schmitz wrote:
Quote:
Richard Heathfield wrote:
<snip>
Quote:
>unsigned long double is not in the list. MSVC6 does indeed fail to
>diagnose it (which I haven't checked), so that's a conformance
>violation. Good spot. If the problem exists in their latest release
>too, you should consider raising a bug report, and let's hope that
>Microsoft treats you better than the lcc-win32 guy treats people who
>report bugs to him.
>
To be fair: Jacob fixes these bugs way quicker than Microsoft. 'treat' here
comes in 2 flavours, fixing bugs in a timely fashion and attitude towards
(potential) customers and users. Mircrosoft might be better at the later,
Jacob is much better at the former.
>
Just for the record: MSVC 8.0 AKA Visual Studio 2005 still has that bug.
I've tried with MSVC 9.0 in Visual Studio Express 2008 and it also still
fails to diagnose unsigned long double with /Za /Wall /W4.
Joachim Schmitz
Guest
 
Posts: n/a
#10: Jul 16 '08

re: Diagnostics (continued)


Iman S. H. Suyoto wrote:
Quote:
Joachim Schmitz wrote:
Quote:
>Richard Heathfield wrote:
><snip>
Quote:
>>unsigned long double is not in the list. MSVC6 does indeed fail to
>>diagnose it (which I haven't checked), so that's a conformance
>>violation. Good spot. If the problem exists in their latest release
>>too, you should consider raising a bug report, and let's hope that
>>Microsoft treats you better than the lcc-win32 guy treats people who
>>report bugs to him.
>>
>To be fair: Jacob fixes these bugs way quicker than Microsoft.
>'treat' here comes in 2 flavours, fixing bugs in a timely fashion
>and attitude towards (potential) customers and users. Mircrosoft
>might be better at the later, Jacob is much better at the former.
>>
>Just for the record: MSVC 8.0 AKA Visual Studio 2005 still has that
>bug.
>
I've tried with MSVC 9.0 in Visual Studio Express 2008 and it also
still fails to diagnose unsigned long double with /Za /Wall /W4.
And I reported it to Microsoft just now.
Curious about their response 8-)

Bye, Jojo


lawrence.jones@siemens.com
Guest
 
Posts: n/a
#11: Jul 17 '08

re: Diagnostics (continued)


Keith Thompson <kst-u@mib.orgwrote:
Quote:
>
(IMHO "const" belongs on the object declaration, not buried in a
typedef, but the language allows it.)
And, as I recall, one of the key arguments for allowing redundant
qualifiers in C99 was that sig_atomic_t is allowed to be a volatile
qualified type and without allowing redundant qualifiers there was no
portable way to declare an object of that type that was *guaranteed* to
be volatile.
--
Larry Jones

Fortunately, that was our plan from the start. -- Calvin
CBFalconer
Guest
 
Posts: n/a
#12: Jul 17 '08

re: Diagnostics (continued)


Ben Bacarisse wrote:
Quote:
Richard Heathfield <rjh@see.sig.invalidwrites:
Quote:
>jacob navia said:
>
<snip>
>
Quote:
Quote:
>>Besides, MSVC emitted just a warning for repeated qualifiers
>>like "const long const long"... Isn't that an error?
>>
>It's a constraint violation, requiring a diagnostic message. It
>appears that in this case MSVC /does/ issue a diagnostic message,
>so that's fine.
>
Just to clear this up a bit... It is a constraint violation in
C90 (for two reasons) but it is not one in C99. Firstly, because
long long is a permitted type in C99 and secondly the specific
constraint about the same type qualifier appearing more than once
had been removed.
Point of pedantry: What constitutes a type name? We know "long
long" qualifies, and that type names can be modified with "const"
etc. Some of the modifications are allowed to recur. However, the
type name has to be accurate, and I move that "long <otherlong"
is not "long long". Therefore "long const long" can never describe
a long long type.


--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Keith Thompson
Guest
 
Posts: n/a
#13: Jul 17 '08

re: Diagnostics (continued)


CBFalconer <cbfalconer@yahoo.comwrites:
[...]
Quote:
Point of pedantry: What constitutes a type name?
[...]

Simple answer: See C99 6.7.6, "Type names".

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer
Guest
 
Posts: n/a
#14: Jul 17 '08

re: Diagnostics (continued)


Keith Thompson wrote:
Quote:
CBFalconer <cbfalconer@yahoo.comwrites:
[...]
Quote:
Point of pedantry: What constitutes a type name?
[...]
>
Simple answer: See C99 6.7.6, "Type names".
I can't quickly translate that into what I need. My point is that
all other names are single identifiers. If we specify the long
long type as being signified by the succession of two 'long' words,
that doesn't allow anything between them. If some thing does so
appear, then we have a long specification, something else, and
another long specification, with no 'long long' specification.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


Closed Thread