Warnings in lcc-win

[Flash Gordon]

Mark McIntyre wrote, On 29/09/07 13:46:

But thats ok - hardly any compilers warn properly at the default
level.

For the code in question I would consider not warning on the default
level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode where it
claims conformance to some version of the standard.

Sure - but you might want to mention this to all the other compiler
writers too...

If I am in a discussion with another compiler writer and their compiler
does not do this I will be sure to mention it.

 

[CBFalconer]

I think we are talking about two different things, here? I am talking
about defining a function, possibly with external linkage, with a K&R
style definition, I am NOT talking about K&R style declaration versus
prototype declaration, not definition:

type func() { /* body */ }

...or even:

static type func() { /* body */ }

For the moment, let's assume the latter. This is a definition, that
also happens to be a declaration, as all functions definitions are
also function declarations.

Are you saying that as long as this appears before any call to func()
in the translation unit, there is no reason to prefer func() over
func(void) in the definition?

Or are we, as I suspect, just addressing two slightly different
points?

I was assuming func() was purely shorthand for the message, and
wasn't considering K&R format at all. I was only addressing the
location and existance of prototypes.

The sequence is confusing, so I haven't snipped anything.

 

[CBFalconer]

.... snip ...

For the code in question I would consider not warning on the
default level to be poor QoI since the code was clearly erroneous.

Also, Jacob has not told us what the compiler does in the mode
where it claims conformance to some version of the standard.

What it does in _any_ other mode is of no interest, and is
off-topic, in this newsgroup.

 

[Chris Hills]

What it does in _any_ other mode is of no interest,

Maybe to you but is of interest to others.

and is
off-topic, in this newsgroup.

Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

 

[CBFalconer]

Maybe to you but is of interest to others.


Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

 

[santosh]

Maybe to you but is of interest to others.


Only for a small group of net nannies. As far as the rest of us are
concerned it is on topic.

You might take a look at Richard Heathcliffs thread [ ... ]

This is the funniest typo(?) I've seen in some time.

 

[Chris Hills]

You might take a look at Richard Heathcliffs thread on 'broaden the
topicality', and the opinions showing up there. You are in the
small group, which may possibly exceed 2.

It exceeds 2 by quite a way. Every time this gets discussed it is the
same SMALL group of net nannies and a larger and now more vocal group
that are getting fed up with them.

 

[Richard Heathfield]

Chris Hills said:

<[email protected]> writes

It exceeds 2 by quite a way.

Yes, you're right - it appears to be 3 rather than 2.

Every time this gets discussed it is the
same SMALL group of net nannies and a larger and now more vocal group
that are getting fed up with them.

The group of people posting in that thread who share your views currently
includes Richard Riley, Kenny McCormack, and - nobody else. At least a
dozen people have expressed a contrary view.

I'll compile statistics in a day or two. Unfiltered, of course (which means
I'll have to turn off my killfile for the purpose, but c'est la vie).

 

[Philip Potter]

Chris Hills said:


Yes, you're right - it appears to be 3 rather than 2.

Don't look at him in that tone of voice.

The group of people posting in that thread who share your views currently
includes Richard Riley, Kenny McCormack, and - nobody else. At least a
dozen people have expressed a contrary view.

In this thread, the phrase being contested is CBFalconer's:

"What it does in _any_ other mode is of no interest, and is
off-topic, in this newsgroup."

This would be contested by anyone in your Moderate group and possibly by
some in your Conservative group. Most people have claimed to be
Conservative in that thread, with some (including Chris Torek) claiming
some leaning towards Moderate.

I wouldn't say that this expresses their position to be for or against
the above statement. I fail to see how you got your "at least a dozen"
figure using only statements from that thread.

Incedentally, I feel that although CBFalconer was strictly correct about
topicality, he was rude about policing it, and stifling discussion which
might be of interest to people still taking part in that thread.

We discuss the behaviour of gcc and msvc in their default
(nonconforming) modes here, why not lcc-win32?

I'll compile statistics in a day or two. Unfiltered, of course (which means
I'll have to turn off my killfile for the purpose, but c'est la vie).

You have to be very careful when compiling statistics from points of
view. The only meaningful one you can extract is a bar chart with one
bar of height one per person...

 

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

The group of people posting in that thread who share your views
currently includes Richard Riley, Kenny McCormack, and - nobody else. At
least a dozen people have expressed a contrary view.

In this thread, the phrase being contested is CBFalconer's:

"What [a compiler] does in _any_ other mode [other than conforming mode]
is of no interest, and is off-topic, in this newsgroup."

This would be contested by anyone in your Moderate group and possibly by
some in your Conservative group.

Unlikely. After all, in non-conforming mode, a compiler can do anything it
likes - it can, for example, reject or mistranslate correct programs, and
it can accept incorrect programs (without producing a diagnostic message
for any syntax errors or constraint violations such a program may
contain). Without specifying in *which* ways a non-conforming mode does
not conform, a discussion of non-conforming mode is indeed of no interest
to comp.lang.c. A "Moderate" might reasonably take the view that a
/particular/ non-conforming mode could be full of quiet interest, and
indeed it might, but arbitrarily discarding conformance is not the
position of a conservative or even a moderate comp.lang.c subscriber.

Most people have claimed to be
Conservative in that thread, with some (including Chris Torek) claiming
some leaning towards Moderate.

Indeed. In fact, I'm rather more liberal than most of those who have so far
expressed an opinion in that thread (but no more so than Chris, I think).

I wouldn't say that this expresses their position to be for or against
the above statement. I fail to see how you got your "at least a dozen"
figure using only statements from that thread.

I would argue that the behaviour of any compiler invoked in a mode that
discards the rules of the language is not a behaviour that con/mod clc
subscribers would find particularly interesting as far as C is concerned.
(Those same people may, of course, find such a discussion absolutely
fascinating if it were set in a more appropriate context, such as
comp.programming or an implementation-specific group.)

Incedentally, I feel that although CBFalconer was strictly correct about
topicality, he was rude about policing it, and stifling discussion which
might be of interest to people still taking part in that thread.

Yes, I know. Some of the netcops in clc make you glad they're not cops IRL.

We discuss the behaviour of gcc and msvc in their default
(nonconforming) modes here,

Such discussions are not topical, and I for one would prefer them to be
conducted in gnu.gcc.help or microsoft.public.vc

why not lcc-win32?

Why gcc and msvc?

You have to be very careful when compiling statistics from points of
view. The only meaningful one you can extract is a bar chart with one
bar of height one per person...

I know. Actually, I don't *have* to be very careful - but I will
nevertheless at least try to be a bit careful.

 

[CBFalconer]

Chris Hills said:

Yes, you're right - it appears to be 3 rather than 2.


The group of people posting in that thread who share your views
currently includes Richard Riley, Kenny McCormack, and - nobody
else. At least a dozen people have expressed a contrary view.

I'll compile statistics in a day or two. Unfiltered, of course
(which means I'll have to turn off my killfile for the purpose,
but c'est la vie).

Oh my - McCormack must be rubbing his hands in glee.

 

[Philip Potter]

Philip Potter said:

Richard Heathfield wrote:

The group of people posting in that thread who share your views
currently includes Richard Riley, Kenny McCormack, and - nobody else. At
least a dozen people have expressed a contrary view.

In this thread, the phrase being contested is CBFalconer's:

"What [a compiler] does in _any_ other mode [other than conforming mode]
is of no interest, and is off-topic, in this newsgroup."

This would be contested by anyone in your Moderate group and possibly by
some in your Conservative group.

Unlikely. After all, in non-conforming mode, a compiler can do anything it
likes - it can, for example, reject or mistranslate correct programs, and
it can accept incorrect programs (without producing a diagnostic message
for any syntax errors or constraint violations such a program may
contain). Without specifying in *which* ways a non-conforming mode does
not conform, a discussion of non-conforming mode is indeed of no interest
to comp.lang.c. A "Moderate" might reasonably take the view that a
/particular/ non-conforming mode could be full of quiet interest, and
indeed it might, but arbitrarily discarding conformance is not the
position of a conservative or even a moderate comp.lang.c subscriber.

But CBF said that what it does in _any_ other mode is off-topic. The
opposite view is not "arbitrarily discarding conformance" but "taking
interest in particular nonconforming modes", just like you said a
Moderate might agree with. ("For all x, x is offtopic" negated is "There
exists an x, such that x is ontopic".)

Indeed. In fact, I'm rather more liberal than most of those who have so far
expressed an opinion in that thread (but no more so than Chris, I think).


I would argue that the behaviour of any compiler invoked in a mode that
discards the rules of the language is not a behaviour that con/mod clc
subscribers would find particularly interesting as far as C is concerned.
(Those same people may, of course, find such a discussion absolutely
fascinating if it were set in a more appropriate context, such as
comp.programming or an implementation-specific group.)

Ah, now your response has enlightened me to something which I hadn't
considered before, which is this:

clc regulars are /not/ simply interested in standard C. They are also
interested in the C community, general practicalities when using C
compilers, tools for aiding C development, and others. None of the
following are mentioned in the C standard, yet they are discussed and
not clamped down on by netcops:

* Profilers (often mentioned as a reposte to "++i is faster than i++!"
and the like)
* Memory leak detectors, in general (talking about specific ones like
valgrind is offtopic though)
* Data structures and algorithms (a woefully inefficient program will be
fixed here rather than redirected to comp.programming)
* Lint and clones
* The presence of command-line switches on compilers in general

This final one is the crux of the matter in this subthread. Below you
ask "why gcc and msvc?". Because in their default mode, they are
nonconforming; yet many newbies to the group do not realise this and
compile their programs with a nonconforming compiler. In order to
explain their error to them, one explain not just that the default mode
is nonconforming, but /why/ it is nonconforming. This is certainly not
part of a discussion of standard C.

Further, the discussion of compiler switches is not restricted to
achieving a conforming mode. The regulars here advocate turning the
warning level on your compiler as high as possible on a regular basis;
this is way outside the scope of the C standard.

The regulars here even /give examples/ of bad behaviour from gcc in
default mode. This is a discussion of a particular nonconforming
compiler which I think is appropriate here.

The phrase '-ansi -pedantic -W -Wall' is of dubious topicality, but it
is always welcome.

[The phrase '-std=c99 -pedantic -W -Wall' is slightly less welcome ]

 

[CBFalconer]

Philip Potter said:
.... snip ...


Yes, I know. Some of the netcops in clc make you glad they're not
cops IRL.

While my answers may be short (or taut), I don't consider them
rude. Why do you? In fact, I tend to avoid rudeness (IMO) at all
times.

 

[Keith Thompson]

While my answers may be short (or taut), I don't consider them
rude. Why do you? In fact, I tend to avoid rudeness (IMO) at all
times.

Since you ask ...

When someone posts a program or code snippet that uses some
non-standard feature, you sometimes assert that it doesn't exist (not
that it's non-standard, but that it doesn't exist at all) and/or
suggest that the poster needs to provide an implementation for the
construct in portable standard C.

I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

 

[CBFalconer]

Since you ask ...

When someone posts a program or code snippet that uses some
non-standard feature, you sometimes assert that it doesn't exist (not
that it's non-standard, but that it doesn't exist at all) and/or
suggest that the poster needs to provide an implementation for the
construct in portable standard C.

I'll use fork() as a (perhaps hypothetical) example.

The valid point, of course, is that fork() is not part of standard C,
and is therefore off-topic here in comp.lang.c. But I submit that
when you respond as I've described above, you're being less than
helpful. Someone who's trying to solve a problem in his program that
uses fork() is interested in getting a solution, not in conforming to
the topicality rules of comp.lang.c. A helpful answer is to point out
that fork is non-standard, and to suggest posting to a system-specific
newsgroup. Pretending (I assume it's a pretense) that you don't know
what fork() really is, or at least have a pretty good idea that it's
Unix-specific, is disingenuous. Nobody is *really* going to provide a
portable standard C implementation of fork().

OK, thanks. I shall try to bear it in mind.

 

[Old Wolf]

Now why would you say that? To my mind, prototypes have just two
purposes: 1. Expose the calling sequence to other files, and 2.
Resolve indirect recursive calls.

Surely the primary purpose is to ensure that all
calls to the function pass the correct count and
type of arguments, and receive the return value
correctly.

 

[Old Wolf]

jacob navia wrote, On 29/09/07 08:34:


In that case at the default warning level it does not conform to the C
standard.

gcc does not conform to the C standard at default
warning level either.

I don't think it's a compiler's job to enforce the
writer to write portable code. I'm quite happy with
compilers accepting code that is guaranteed to work
on that particular implementation, in their default
mode of operation. Another example is // comments
in C90 code.

Those programmers who do want portability can invoke
the compiler in the mode that conforms to the C standard.

 

[CBFalconer]

Surely the primary purpose is to ensure that all calls to the
function pass the correct count and type of arguments, and receive
the return value correctly.

No, because that is handled by the declaration before use
requirement. In:

double foo(double d) {....; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

The definition of foo acts as a declaration and prototype. No
copying needed.

 

[Old Wolf]

No, because that is handled by the declaration before use
requirement.

No it isn't; e.g.

int memset();

int main()
{
char x[4];
memset(x, sizeof x, 100);
}

 

[Keith Thompson]

No, because that is handled by the declaration before use
requirement. In:

double foo(double d) {....; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

The definition of foo acts as a declaration and prototype. No
copying needed.

Replace "No, because" by "Yes, and", and I'll agree with you.

As you say, the definition of foo provides a prototype. The purpose
of doing so is precisely "to ensure that all calls to the function
pass the correct count and type of arguments, and receive the return
value correctly".

The alternative would be:

double foo(d) double d; { ...; return d;}

int main(void) {
...
d = foo(d);
...
return 0;
}

where the definition of foo *doesn't* provide a prototype, even though
it's defined before it's used.