When to emit diagnistics

[CBFalconer]

jacob navia wrote:
.... snip ...

Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.

[...]

Not quite. With "/W4", MSVC does emit this:

In my experience (about 9 years old) using /W4 is impossible, since
MSVC then checks all its own system .h files, and spits out an
unholy mess of error/warning messages.

 

[Keith Thompson]

C++ is more yet more strict, the example you posted is a syntax error to
a C++ compiler.

The example in question was:

void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }

In C, this has no syntax errors, but it does violate a constraint, so
a diagnostic message is required. (Since the standard doesn't
distinguish between diagnostic messages for syntax errors and
diagnostic messages for constraint violations, the effect is the
same.)

<OT>The situation in C++ is similar.</OT>

(I don't see how C++ is relevant here.)

 

[Flash Gordon]

Ian Collins wrote, On 14/07/08 08:23:

In that case use minimum warning levels and lint.

Or use maximum (or some balance) warning level and then justify the
deviation at the review. Where I used to work we had a rule of "no
warnings" *but* if you could justify at review a small number of
warnings this would be accepted.

 

[Flash Gordon]

jacob navia wrote, On 14/07/08 13:49:

Hello,

jacob navia wrote:

Recently we had a discussion about the following code:

void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }
[...]

Note that Microsoft C, for instance will not diagnose this
even with the highest warning level.
This is not true. I just tried it with Visual C++ 6.0, all service
packs
applied:

default settings: (warning level 3): No warning
incremented warning level to 4: No warning

warning level back to 3, but "disable language extensions" active:

C:\test\a.c(9) : warning C4133: 'function' : incompatible types -
from 'int *' to 'long *'

This is exactly what I have expected.

And the considerably younger VC 8.0, AKA Visual Studio 2005, is giving
exatly the same warning, down to warning level 1, as long as language
extension are disabled (i.e. working in conforming mode).

I did not know that you have to disable language extensions
to get a warning.

How many compilers do you know of that conform to the standard by
default? I can't think of any and I am certain they are in a
considerable minority.

Anyway, that obscure option matches lcc -A -A obscure option.

No, in MSVC it is *not* an obscure option. It is an option clearly
visible in the GUI and described in the documentation. Based on reports
here (which you have not denied) you double -A is not described in your
documentation.

 

[ian-news]

[...]

C++ is more yet more strict, the example you posted is a syntax error to
a C++ compiler.

The example in question was:

void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }

<OT>The situation in C++ is similar.</OT>

(I don't see how C++ is relevant here.)

It probably isn't. It's just one of my pet gripes about C: C isn't
strict enough on type matching. I think C should have moved more in
the C++ direction and required stricter type matching.

Ian.

 

[CBFalconer]

jacob navia wrote:
.... snip ...


Is that slapdash blinkered attitude typical of windows programmers?

What you consider pedantic most professional programmers would
consider attention to detail. Thank goodness NASA programmers
don't share your attitude.

The last couple of days there was something in comp.arch.embedded
(I think - maybe it was here) about the fact that the last Mars
lander was programmed in C. I added something about the
requirement for good programmers, to do that. I can just envision
Jacob writing code for that system.

 

[jacob navia]

Is that slapdash blinkered attitude typical of windows programmers?

What you consider pedantic most professional programmers would consider
attention to detail. Thank goodness NASA programmers don't share your
attitude.

Details of no practical significance are crucial yes.

C++ is more yet more strict, the example you posted is a syntax error to
a C++ compiler.

If you like C++ then please go to the comp.lang.c++ group.
There is no point in contributing to this group.

In all the conversation I have had with you, the only thing that
clearly comes out of your messages is that C++ is far better than C.

OK. You are right. Then accept the consequences and go to that group.

 

[Keith Thompson]

Details of no practical significance are crucial yes.

So lcc-win doesn't issue a diagnostic when you pass an int* argument
to a function that expects a long*. You claim that, since int and
long happen to have the same representation, such a diagnostic is of
no practical significance (in spite of the fact that the standard
absolutely requires such a diagnostic for any conforming
implementation).

Why then does lcc-win issue a diagnostic when you assign an int* value
to a long* object, or use an int* value to initialize a long* object?

Specifically, of the three following programs:

void f(long *lp) { *lp = 0; }
int main(void) { int i; f(&i); return i; }

int main(void) { int x = 0; long *lp = &x; return *lp; }

int main(void) { int x = 0; long *lp; lp = &x; return *lp; }

why does lcc-win emit diagnostics for the second and third, but not
for the first?

 

[ian-news]

Details of no practical significance are crucial yes.

So standard conformance and portablity are of no practical
significance?

In all the conversation I have had with you, the only thing that
clearly comes out of your messages is that C++ is far better than C.

Well it is in many ways (by design). But C is still C and sloppy
programming is sloppy programming in any language. I only mentioned C+
+ to illustrate that the compiler can and should help root out sloppy
practices.

Ian

 

[Keith Thompson]

The types char, signed char, and unsigned char are three distinct
types, even though two of these types are guaranteed to be the same.

[...]

To be just a trifle more precise, two of them are guaranteed to have
the same range, representation, and behavior. They remain, as you
said, three distinct types.

 

[Nick Keighley]

you know if you tried listening to people and thinking about
what they say you might learn something interesting.

Let's take it in gentle steps. C provides a long type and an int
type. Why? Sometimes a programmer (eg. me) selects int in other cases
long can you speculate why he (ie. me) might do that?

One of the things I worry about is portability. Not because of
academic piffle but becuase of real world experience of programs
outliving their hardware. Software written in the 80's and 90's
is still running. And still doing useful work. A while ago we
(the programming community) had the horrors of moving from 16-bit
to 32-bit. Now we face 32-bit to 64-bit. People will store
addresses in ints or longs. People will use those "spare bits"
in the 24-bit colour type.

One of the nice thinsg about C is you *can* write portable
software. I'm porting old sun stuff to linux at the moment.
A program I've worked on has moved from HP-UX to Windows.

*some* implementations

no


Details of no practical significance are crucial yes.

I don't think NASA programmers can be accused of being impractical...

<snip>

--
Nick Keighley

"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare

 

[Joachim Schmitz]

Flash Gordon wrote:

How many compilers do you know of that conform to the standard by
default? I can't think of any and I am certain they are in a
considerable minority.

I know of one. It is called c89 and runs on NonStop Kernel (a propriatary
OS). There you have to switch on extensions
(-Wextensions, -Wallow_cplusplus_comments, -Wc99lite etc.)

Bye, Jojo

 

[lawrence.jones]

Because under windows (32 and 64 bits) there is
absolutely no PRACTICAL difference between a
long and an int. They are completely equivalent types.

The diagnostic would just add CLUTTER and NOISE to
the output of the compiler.

Unless you're interested in porting your code to an environment where
they *aren't* completely equivalent types. In that case, you really
*do* want to know that you've screwed up your code.

How seriously to take such mismatches is an engineering decision that
each implementor needs to make based on their own environment and
customer base. Some implementors consider it an error by default,
others warn about it by default, others require special options before
it is diagnosed. In my opinion, it would be better if lcc-win diagnosed
it at a lower warning level than it currently does, but your decision
not to is entirely reasonable, too.