Hi all,Just wondering are there any problems with learning c from older
books,as I have picked up some from 1988,1994,1997,1998.
By using books of this age(Im on a tight budget)am I going to missout on
anything in the langauge or has C remaind similar.
I intend to use Dev-C++ on the windows platform.
If any one feels theres anything I should be aware of,please help me out,I
feel a bit lost with all thats out there regarding this language.
Many thanks.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05
90  3731  da**************@gmail.com (Daniel Vallstrom) writes: Tim Rentsch <tx*@alumnus.caltech.edu> wrote in message news:<kf*************@alumnus.caltech.edu>... Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
>Da*****@cern.ch (Dan Pop) writes:
>[snip]
>> From the gcc man page:
>>
>> -Wall
>> All of the above -W options combined. This enables all the
>> warnings about constructions that some users consider ques*
>> tionable, and that are easy to avoid (or modify to prevent the
>> warning), even in conjunction with macros.
>>
>> The following -W... options are not implied by -Wall. Some of
>> them warn about constructions that users generally do not consider
>> questionable, but which occasionally you might wish to check for;
>> others warn about constructions that are necessary or hard to
>> avoid in some cases, and there is no simple way to modify the code
>> to suppress the warning.
>>
>> -W Print extra warning messages for these events:
>
>More seriously, I'm not sure what point you're trying to make.
Nothing more than the gcc documentation itself says: -Wall flags stuff
that is trivial to avoid and that many people don't like,
That may be what they mean but it isn't what they say.
They do too!-) (IMO FWIW, more or less).
Clearly not. The documentation says "some"; it does not say "many".
>The -Wall includes "all warnings about constructions that some users
>consider questionable". Taken literally, this would mean that any
>construction that any user considered questionable would be included
>in -Wall.
??? By what kind of logic has "some" become "any"?
The standard rules for how English is translated into mathematical
logic and predicate calculus.
-Wall == { warnings w | there exists some users that consider
constructs flagged by w questionable }
Sweet! There are standard rules for translating arbitrary English into
a formal language!?!
To be more exact, there are standard rules for how certain English
constructs are understood to be formulated in the language of the
predicate calculus. It's called Logic.
Do you have success applying the rules in daily life?-)
Yes I do, when talking with people who have attained a certain level
of technical education.
Anyway,
"all warnings about constructions that some users consider
questionable"
clearly means something like
all warnings about constructions that this small, specific,
more or less fixed, authoritative group of users consider
questionable.
Otherwise it doesn't make sense since for every construct there
is always some luddite that finds it questionable.
You don't mean it doesn't make sense; you mean you disagree with what
it says. The meaning that "-Wall warns on all constructs that any user
found questionable" is perfectly sensible even if it happens to be false.
Incidentally, you can tell a lot about the quality of someone's
arguments by their attitude toward using words like "luddite" as
part of their arguments.
You've got a set of users, "some users" and you put all the warnings
all the users from that set agree upon under -Wall.
The interpretation you're suggesting is analogous to the well-known
joke:
"They say that in New York city a man is run over every 5 minutes."
"The poor fellow!"
It's possible the first person meant the same man was run over every
time, but that's not the usual interpretation.
And? It's the right interpretation in the -Wall case. It only needs to
be a possible interpretation, which it is --- otherwise the joke
wouldn't work.
I didn't say it wasn't possible to interpret it that way. It's also
possible to interpret it as "-Wall includes all the warnings for
constructs that GNU developers find questionable", and I wouldn't be
surprised if that interpretation were closer to the truth than most of
the others that have been mentioned. But I'm not talking about how it
should be interpreted; I'm talking about what the words literally
say.
>Obviously that's not right, but let's skip that right now.
Indeed, but the mistake is yours.
I think everyone would benefit, Dan, if you put a little more effort
into explaining your point of view rather than assuming that your
point of view is true and simply stating it as a fact.
He has explained (IMO, FWIW).
He stated his point of view clearly. He did not offer motivation,
reasoning, examples or evidence. That's more like what I mean by
"explaining".
Besides, explaining takes time and just
an empty flame from someone might get you to reconsider --- especially
if the empty flame or statement is from someone that usually is right.
On the contrary, the more often someone makes statements that appear
to be just personal opinion, or don't distinguish between statements
of opinion and statements of fact, and don't offer reasoning or
evidence, the more likely it seems that their comments would be
dismissed. As for taking time, well, perhaps it does, but plenty of
other posters do so. OK, what are the problematic warnings triggered by -Wall?
I'm happy to go through the list of -W<something> options covered by
-Wall and see which ones I've found helpful and which not, if you will
also do that for the set of constructs covered by the -W option.
[stuff about -Wparentheses snipped]
-Wextra (-W) warns about the idiom
p0 == p1 == ... == pn
even when pi is 0 or 1, or of type bool. This is unfortunate.
Do you mean this to be the only warning covered under -W (aka -Wextra)
that you find objectionable?
I'm still hoping Dan will weigh in with his views on which of
the -W constructs are ones he finds troublesome.
Tim Rentsch wrote: da**************@gmail.com (Daniel Vallstrom) writes:
Tim Rentsch <tx*@alumnus.caltech.edu> wrote in message news:<kf*************@alumnus.caltech.edu>...
Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
>Da*****@cern.ch (Dan Pop) writes:
>[snip]
>
>>From the gcc man page:
>>
>> -Wall
>> All of the above -W options combined. This enables all the
>> warnings about constructions that some users consider ques*
>> tionable, and that are easy to avoid (or modify to prevent the
>> warning), even in conjunction with macros.
>>
>> The following -W... options are not implied by -Wall. Some of
>> them warn about constructions that users generally do not consider
>> questionable, but which occasionally you might wish to check for;
>> others warn about constructions that are necessary or hard to
>> avoid in some cases, and there is no simple way to modify the code
>> to suppress the warning.
>>
>> -W Print extra warning messages for these events:
>
>More seriously, I'm not sure what point you're trying to make.
Nothing more than the gcc documentation itself says: -Wall flags stuff
that is trivial to avoid and that many people don't like,
That may be what they mean but it isn't what they say.
They do too!-) (IMO FWIW, more or less).
Clearly not. The documentation says "some"; it does not say "many".
Written English is not a formal language. It does not, much
though I wish otherwise, admit of a single unambiguous interpretation
in many cases.
("No language is capable of unambiguously expressing every
idea, least of all this one.")
>The -Wall includes "all warnings about constructions that some users
>consider questionable". Taken literally, this would mean that any
>construction that any user considered questionable would be included
>in -Wall.
??? By what kind of logic has "some" become "any"?
The standard rules for how English is translated into mathematical
logic and predicate calculus.
-Wall == { warnings w | there exists some users that consider
constructs flagged by w questionable }
Sweet! There are standard rules for translating arbitrary English into
a formal language!?!
To be more exact, there are standard rules for how certain English
constructs are understood to be formulated in the language of the
predicate calculus. It's called Logic.
No, that's not what logic is. And indeed, even such rules as do
exist apply only in certain situations.
Do you have success applying the rules in daily life?-)
Yes I do, when talking with people who have attained a certain level
of technical education.
And people with something approaching mastery of basic
logic, coupled with good language skills, work at avoiding
applying the rules inappropriately.
Anyway,
"all warnings about constructions that some users consider
questionable"
clearly means something like
all warnings about constructions that this small, specific,
more or less fixed, authoritative group of users consider
questionable.
Otherwise it doesn't make sense since for every construct there
is always some luddite that finds it questionable.
You don't mean it doesn't make sense; you mean you disagree with what
it says.
No; it really is unreasonable to interpret the "some" there
too literally. (Clue: if a literal reading would obviously
make a sentence incorrect, it is usually the case that a less
literal, more charitable reading will give the intended
meaning. In the world of mathematics of a reasonably advanced
level, it's even common to state things which are not literally
true, knowing that the audience will realize that a literal
interpretation is not intended, and "abuse of language" is
involved to aid communication.)
The meaning that "-Wall warns on all constructs that any user
found questionable" is perfectly sensible even if it happens to be false.
Incidentally, you can tell a lot about the quality of someone's
arguments by their attitude toward using words like "luddite" as
part of their arguments.
But not as much as you might invite people to believe. You've got a set of users, "some users" and you put all the warnings
all the users from that set agree upon under -Wall.
The interpretation you're suggesting is analogous to the well-known
joke:
"They say that in New York city a man is run over every 5 minutes."
"The poor fellow!"
It's possible the first person meant the same man was run over every
time, but that's not the usual interpretation.
And? It's the right interpretation in the -Wall case. It only needs to
be a possible interpretation, which it is --- otherwise the joke
wouldn't work.
I didn't say it wasn't possible to interpret it that way. It's also
possible to interpret it as "-Wall includes all the warnings for
constructs that GNU developers find questionable", and I wouldn't be
surprised if that interpretation were closer to the truth than most of
the others that have been mentioned. But I'm not talking about how it
should be interpreted; I'm talking about what the words literally
say.
Wasted effort?
[snip]
-- James
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes: I'm still hoping Dan will weigh in with his views on which of
the -W constructs are ones he finds troublesome.
I haven't noticed you answering my similar question about -Wall and I
was the first to ask!
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
James Dennett <jd******@acm.org> writes: Tim Rentsch wrote:
[snip]
To be more exact, there are standard rules for how certain English
constructs are understood to be formulated in the language of the
predicate calculus. It's called Logic.
No, that's not what logic is. And indeed, even such rules as do
exist apply only in certain situations.
You're right in the sense that Logic includes other topics. But the
correspondence between certain constructs in English and formulas in
predicate calculus is covered in courses on Logic; see for example
this Logic course webpage: http://www.luc.edu/faculty/avande1/l...ge-details.htm [snip]
You don't mean it doesn't make sense; you mean you disagree with what
it says.
No; it really is unreasonable to interpret the "some" there
too literally. (Clue: if a literal reading would obviously
make a sentence incorrect, it is usually the case that a less
literal, more charitable reading will give the intended
meaning. In the world of mathematics of a reasonably advanced
level, it's even common to state things which are not literally
true, knowing that the audience will realize that a literal
interpretation is not intended, and "abuse of language" is
involved to aid communication.)
If you go back and read the article with my comment that started this
subthread, you'll see that I said something like "if the documentation
text is taken literally, that would mean <X>, and that's not right."
And that's completely consistent with your paragraph. I wasn't saying
anything about how the text should be interpreted; the comment was
only about what the text literally said (and it was tangential comment
at that).
I have the sense that some of the people responding think I'm being
overly pedantic in my reading of the documentation text. That seems
pretty humorous, considering the enormous number of times that an
article posted in comp.lang.c will exhibit a characteristic (similar
to the gcc documentation text) with a writer saying one thing where he
obviously means something else, and counter-posters immediately pounce
on the "error" and correct him.
Disclaimer: the snips were big. I tried to leave enough context
so that the responses could be understood and the sense of what
is being responded to remains fair. Da*****@cern.ch (Dan Pop) writes: In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
I'm still hoping Dan will weigh in with his views on which of
the -W constructs are ones he finds troublesome.
I haven't noticed you answering my similar question about -Wall and I
was the first to ask!
That's right, you were:
OK, what are the problematic warnings triggered by -Wall?
And I responded:
I'm happy to go through the list of -W<something> options covered by
-Wall and see which ones I've found helpful and which not, if you will
also do that for the set of constructs covered by the -W option.
Since you hadn't replied to that, probably I shouldn't have brought
it up again and just let the matter drop. My apologies.
Tim Rentsch wrote: Da*****@cern.ch (Dan Pop) writes: Tim Rentsch <tx*@alumnus.caltech.edu> writes:
I'm still hoping Dan will weigh in with his views on which of
the -W constructs are ones he finds troublesome.
I haven't noticed you answering my similar question about -Wall
and I was the first to ask!
That's right, you were:
OK, what are the problematic warnings triggered by -Wall?
And I responded:
I'm happy to go through the list of -W<something> options
covered by -Wall and see which ones I've found helpful and
which not, if you will also do that for the set of constructs
covered by the -W option.
Since you hadn't replied to that, probably I shouldn't have
brought it up again and just let the matter drop. My apologies.
This is all extremely childish. I routinely use -W -Wall -ansi
-pedantic and add a few extras (-Wwrite-strings -Wfloat-equal).
This is enforced by use of an alias for gcc. If anything about the
combination annoyed me I could simply modify the alias. Meanwhile
I have no idea precisely which options are enabled, and can look
them up if desired.
Since my system (DJGPP) make does not use the shell (4dos) this
aliased default does not affect my makefiles. make in effect uses
bash as the shell, which knows nothing about 4dos aliases (and vice
versa).
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes: Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
>I'm still hoping Dan will weigh in with his views on which of
>the -W constructs are ones he finds troublesome.
I haven't noticed you answering my similar question about -Wall and I
was the first to ask!
That's right, you were:
OK, what are the problematic warnings triggered by -Wall?
And I responded:
I'm happy to go through the list of -W<something> options covered by
-Wall and see which ones I've found helpful and which not, if you will
also do that for the set of constructs covered by the -W option.
Since you hadn't replied to that, probably I shouldn't have brought
it up again and just let the matter drop. My apologies.
I have already posted my objections to -W, about one year ago or so.
I haven't noticed yours to -Wall.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
I'm happy to go through the list of -W<something> options covered by
-Wall and see which ones I've found helpful and which not, if you will
also do that for the set of constructs covered by the -W option.
I have already posted my objections to -W, about one year ago or so.
Ah. I didn't see that posting.
Do you have an article reference or a copy of what you posted? I did
search in Google groups, but even restricting the search to articles
in comp.lang.c, by Dan Pop, and near a year ago, yielded anywhere from
hundreds to thousands of articles. None of them stood out as having
the kind of information I was asking about, so presumably I didn't find
the article you were referring to. Please feel free to send it to me
in email if you don't want to post it again.
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes: Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes: >
> I'm happy to go through the list of -W<something> options covered by
> -Wall and see which ones I've found helpful and which not, if you will
> also do that for the set of constructs covered by the -W option.
I have already posted my objections to -W, about one year ago or so.
Ah. I didn't see that posting.
Do you have an article reference or a copy of what you posted?
I don't keep either references or copies of anything I post.
I did
search in Google groups, but even restricting the search to articles
in comp.lang.c, by Dan Pop, and near a year ago, yielded anywhere from
hundreds to thousands of articles.
Can't you restrict the search to articles containing certain keywords
or sequences of text? "-W" and "unsigned" are your keywords.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
>
> I'm happy to go through the list of -W<something> options covered by
> -Wall and see which ones I've found helpful and which not, if you will
> also do that for the set of constructs covered by the -W option.
I have already posted my objections to -W, about one year ago or so.
[snip]
I did
search in Google groups, but even restricting the search to articles
in comp.lang.c, by Dan Pop, and near a year ago, yielded anywhere from
hundreds to thousands of articles.
Can't you restrict the search to articles containing certain keywords
or sequences of text?
I could and did. Note the word "restricting" in my paragraph above -
I was narrowing the search from just a keyword/keyphrase search,
of which I did several (both before and after the narrowing).
"-W" and "unsigned" are your keywords.
It would have been helpful if you'd mentioned "unsigned" earlier.
Doing a Google Groups search with "-W" and "unsigned", and limiting
the time to Jan 1, 2003, to the present (and in comp.lang.c and with da*****@cern.ch as author) yielded 11 hits. None of these contained
any substantive discussion of different -W options. About the closest
was this: Oct 24 2003, 5:12 am
Newsgroups: comp.lang.c
From: Dan....@cern.ch (Dan Pop)
Date: 24 Oct 2003 11:53:49 GMT
Local: Fri, Oct 24 2003 4:53 am
Subject: Re: comparison between signed and unsigned
In <bn8rur$q4...@newsg2.svr.pol.co.uk> "John Buckley" <u...@example.net> writes:
>In my program I need to compare a long variable with a size_t variable. The
>long variable's value is guaranteed to be positive since it's initialised by
>a function returning a positive value (or -1L when an error occurs, which I
>check for). When I compare these variables with >, I get the warning
>"comparison between signed and unsigned". Given that the long variable is
>guaranteed to hold a positive value, can I ignore this diagnostic or should
>I deal with it in some way?
The best thing to do, if you trust your C skills, is to disable (or not
enable) this warning. Most of the time (or all the time if you know what
you're doing) it is merely a source of noise. gcc -Wall, for example,
does not enable such warnings, leaving them for the masochists who also
use -W.
So either I didn't find the article you mentioned or it didn't
have the kind of information I asked about.
I'm willing to continue the discussion if there is an exchange of
views and an opportunity for both sides to learn. What I am not
willing to do is put in time and effort going through the various
warnings covered under -Wall (and there are lots more under -Wall than
there are under -W), taking the time to write a little something about
each, only to get a response that offers no views of its own but just
argues with mine. So please decide which path you'd like to go down.
Tim Rentsch wrote: da**************@gmail.com (Daniel Vallstrom) writes:
Tim Rentsch <tx*@alumnus.caltech.edu> wrote in message
news:<kf*************@alumnus.caltech.edu>... Da*****@cern.ch (Dan Pop) writes:
[snip discussion about translating ordinary language into
a formal one.]
I can only agree with James Dennett's reply to your post and
I'll just reply to some of your comments. Over all IMO you
take a too positivistic approach. An essential --- and good! ---
characteristic of ordinary language is that it can *not* be
formalized. Sure, there might be a better formulation of what
-Wall mean, but it's no big deal.
Anyway,
"all warnings about constructions that some users consider
questionable"
clearly means something like
all warnings about constructions that this small, specific,
more or less fixed, authoritative group of users consider
questionable.
Otherwise it doesn't make sense since for every construct there
is always some luddite that finds it questionable.
You don't mean it doesn't make sense; you mean you disagree with
what it says. The meaning that "-Wall warns on all constructs that any
user found questionable" is perfectly sensible even if it happens to be
false.
I do mean "it doesn't make sense" (with the meaning that phrase usually
has in ordinary English). Let's agree that the sentence can mean one of
two things:
(1) warn about every character in the file;
(2) warn about this specific set of constructions.
Since (1) "doesn't make sense" (in the ordinary sense of the phrase),
(2) must be what the gcc devs mean.
Incidentally, you can tell a lot about the quality of someone's
arguments by their attitude toward using words like "luddite" as
part of their arguments.
Hm, reading that I get the feeling that you think that I in some way
implied a connection between "luddite" and you. Nothing could be
more wrong. Because surely you can't suggest that the word 'luddite'
should be banned? I used it in the following sense to get to (1) above:
"for every character there exists a luddite that wants to warn about
it" and "there exists a character that only a luddite wants to warn
about":-) Maybe there is a better word but I couldn't find one anyway.
And it doesn't stretch word meaning too far. I just tried to be
specific when I used the word 'luddite'. (Or maybe it was my
"today's word" that I had to use in a sentence:-)
Again, if you think that I implied something disparaging between
the lines you are mistaken. It would also be somewhat ironic since
it is you that argues for a "logical" interpretation of English;p
It's also
possible to interpret it as "-Wall includes all the warnings for
constructs that GNU developers find questionable", and I wouldn't be
surprised if that interpretation were closer to the truth than most
of the others that have been mentioned.
That *is* the interpretation that all of us have been suggesting.
(Here is a link to the manual on gcc's warning options under
discussion:)
http://gcc.gnu.org/onlinedocs/gcc-3....arning-Options
> OK, what are the problematic warnings triggered by -Wall?
I'm happy to go through the list of -W<something> options covered
by -Wall and see which ones I've found helpful and which not, if you
will also do that for the set of constructs covered by the -W option.
[stuff about -Wparentheses snipped]
-Wextra (-W) warns about the idiom
p0 == p1 == ... == pn
even when pi is 0 or 1, or of type bool. This is unfortunate.
Do you mean this to be the only warning covered under -W (aka
-Wextra) that you find objectionable?
I also listed -Wno-sign-compare which turns off -Wsign-compare
included in -Wextra. But other than that, the answer would be
"yes", with a quick reading.
But the fact that I --- like many others? --- also use -Wextra,
amended by -Wno-sign-compare, does not mean that I disagree
with anything stated on gcc's warning man-page about -Wall and
-Wextra.
The only thing I have against -Wall is the braindead &&-|| warning
and you can work around that problem without affecting the code
you write. It would be interesting to hear what you have against
-Wall. If it's the combination -Wall and -Werror that is the
problem then maybe you should skip -Werror instead of the (IMO
and in many others) useful -Wall.
Daniel Vallstrom
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes: Doing a Google Groups search with "-W" and "unsigned", and limiting
the time to Jan 1, 2003, to the present (and in comp.lang.c and with
da*****@cern.ch as author) yielded 11 hits. None of these contained
any substantive discussion of different -W options.
There is only one "-W" option as far as I know. And my main objection
to it is that I get the following kind of warnings:
fangorn:~/tmp 127> cat test.c
int main()
{
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
that cannot be shut up without using a programming style I do not like
(either use of unnecessary casts or proliferation of unsigned variables).
Of course, I could disable this specific warning with -Wno-sign-compare
but I can't find enough value in what's left to justify bothering with
baroque sequences of -W... options.
OTOH, I couldn't find any objectionable warning generated by -Wall when
dealing with correct code. In all cases, shutting such warnings up
results in code whose correctness is clearer than before. -Wall also
helped me get rid of the "implicit int in function definitions" habit
inherited from the K&R C days.
So, what's wrong with -Wall, from your point of view?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
"Dan Pop" <Da*****@cern.ch> wrote in message
news:cp**********@sunnews.cern.ch... In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu>
writes:Doing a Google Groups search with "-W" and "unsigned", and limiting
the time to Jan 1, 2003, to the present (and in comp.lang.c and with
da*****@cern.ch as author) yielded 11 hits. None of these contained
any substantive discussion of different -W options.
There is only one "-W" option as far as I know. And my main objection
to it is that I get the following kind of warnings:
fangorn:~/tmp 127> cat test.c
int main()
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
that cannot be shut up without using a programming style I do not like
(either use of unnecessary casts or proliferation of unsigned variables).
Of course, I could disable this specific warning with -Wno-sign-compare
but I can't find enough value in what's left to justify bothering with
baroque sequences of -W... options.
A perfectly valid warning !
Think of this :
#include <stdio.h>
int main(void)
int i;
for (i = -1; i < sizeof(int); i++) ;
printf("%d\n", i);
return 0;
}
This program outputs -1 contrary to popular belief !
The solution to this problem is this :
#include <stdio.h>
typedef signed whatever ssize_t;
#define ssizeof(t) ((ssize_t)sizeof(t))
int main(void)
int i;
for (i = -1; i < ssizeof(int); i++) ;
printf("%d\n", i);
return 0;
}
No warnings, correct output.
It is really a shame that a cast to the signed version of size_t cannot be done
portably, and that ssize_t is not part of C99 (but it is part of POSIX).
--
Chqrlie.
On Tue, 14 Dec 2004, Charlie Gordon wrote:
"Dan Pop" <Da*****@cern.ch> wrote... There is only one "-W" option as far as I know. And my main objection
to it is that I get the following kind of warnings:
fangorn:~/tmp 127> cat test.c
int main()
{
Incidentally, Charlie, your newsreader seems to be treating the '{'
character as a cue to insert two blank lines and delete the '{'. You
might want to see what might be causing that; it's a very odd behavior.
(I'm basing that assumption on the way you deleted the '{' in both Dan's
code and your own.)
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
A perfectly valid warning !
Think of this :
#include <stdio.h>
int main(void)
{ int i;
for (i = -1; i < sizeof(int); i++) ;
printf("%d\n", i);
return 0;
}
This program outputs -1 contrary to popular belief !
Not a /terribly/ popular belief, of course. :) Besides, nobody's
objecting to that particular warning; obviously in that case the user
is doing something stupid and ought to be warned. But in Dan's example,
the user quite clearly knows what he's doing; not only is '< sizeof foo'
a well-established C idiom, but it can be proven at compile time that
Dan's code does exactly what it would do with or without the extra cast.
So it is entirely /un/reasonable for GCC to emit bogus warnings about it!
The solution to this problem is this :
#include <stdio.h>
typedef signed whatever ssize_t;
I don't think 'whatever' is in my copy of the Standard. ;) If
this version isn't portable without manual tweaking by a C guru for
the platform in question, I don't think Dan's going to like it.
[...] It is really a shame that a cast to the signed version of size_t cannot
be done portably, and that ssize_t is not part of C99 (but it is part of
POSIX).
Yes. Personally, I use '-O2 -W -Wall' and just ignore the bogus
warnings. Other than that one, and an occasional "variable foo may be
used uninitialized," and GCC's annoying spiel discouraging the use of
'tmpnam', I can't recall any more bogus warnings enabled by '-W'. So
I find them not too difficult to ignore. YMMV.
-Arthur
On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
.... fangorn:~/tmp 127> cat test.c
int main()
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
....
A perfectly valid warning !
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
Think of this :
#include <stdio.h>
int main(void)
int i;
for (i = -1; i < sizeof(int); i++) ;
printf("%d\n", i);
return 0;
}
This program outputs -1 contrary to popular belief !
Yes, that's an unfortunate in a lot of cases. However the question is
whether diagnosing potential problems like this is worth the falso
diagnostics for good code. Indeed a reasonable compiler should be able to
work out that i can't be negative in Dan's original loop.
The solution to this problem is this :
#include <stdio.h>
typedef signed whatever ssize_t;
#define ssizeof(t) ((ssize_t)sizeof(t))
You don't even need ssize_t
#define intsizeof(t) ((int)sizeof(t))
Since the code that uses this is testing against an int variable, the
programmer is requiring the size of the object/type to be representable as
an int. Otherwise the code could fail irrespective of whether the cast to
int here is well defined.
Alternatively casting to long or intmax_t as appropriate is as portable as
a created ssize_t, and probably no less efficient where constant
expressions are concerned (i.e. sizeof non-VLAs). Indeed it might work
in cases where ssize_t doesn't.
int main(void)
int i;
for (i = -1; i < ssizeof(int); i++) ; printf("%d\n", i); return
0;
}
}
No warnings, correct output.
It is really a shame that a cast to the signed version of size_t cannot
be done portably, and that ssize_t is not part of C99 (but it is part of
POSIX).
For all intents and purposes it can be done.
Lawrence
Lawrence Kirby wrote: On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
...
fangorn:~/tmp 127> cat test.c
int main()
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
...
A perfectly valid warning !
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
But getting to *improve* your style because of viable compiler
diagnostics is a fine opportunity, no?
-- James
James Dennett wrote:
Lawrence Kirby wrote:
On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
...
fangorn:~/tmp 127> cat test.c
int main()
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
...
A perfectly valid warning !
True, except when the code is clearly correct.
Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
But getting to *improve* your style because of viable compiler
diagnostics is a fine opportunity, no?
That's what I was thinking.
It's good to use operand types which match.
--
pete
On Wed, 15 Dec 2004 21:37:13 -0800, James Dennett wrote:
.... True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
But getting to *improve* your style because of viable compiler
diagnostics is a fine opportunity, no?
That depends on whether you consider cluttered to be a better style than
keeping it simple. There is a legitimate issue that the compiler is
warning about, but it doesn't occur in this case and it is easy to see
that.
Lawrence
"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote: It is really a shame that a cast to the signed version of size_t cannot
be done portably, and that ssize_t is not part of C99 (but it is part of
POSIX).
For all intents and purposes it can be done.
How can it be done ?
C99 doesn't tell us much about the size of size_t, so how can you convert a
size_t expression to its signed equivalent, assuming no overflow, and without
extending precision ?
(intmax_t)sizeof(e) in unacceptable because it potentially extends the
size and changes the semantics of the surrounding expression as in
sizeof(sizeof(e)) != sizeof((intmax_t)sizeof(e))
I advocate casting to (signed) as a lone adjective should do this, but it is
incompatible with current C99 semantics that specify (signed) to be quivalent to
(signed int).
What is your version ?
--
Chqrlie.
On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote: "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote: > It is really a shame that a cast to the signed version of size_t cannot
> be done portably, and that ssize_t is not part of C99 (but it is part of
> POSIX).
For all intents and purposes it can be done.
How can it be done ?
As I suggested previously in the article you responded to.
C99 doesn't tell us much about the size of size_t, so how can you convert a
size_t expression to its signed equivalent, assuming no overflow, and without
extending precision ?
It doesn't have to be the signed equivalent, a type at least as wide as
that will do just as well, if not better if it can represent all size_t
values. So the widest integer type supported by the implementation works.
I do accept that when a wider than necessary type is used in a complex
expression that type will tend to propagate through the expression, a form
of "poisoning".
If you felt it necessary you could in C99 use the preprocessor to find the
largest signed integer type whose positive range does not exceed that of
size_t.
Alternatively you can cast to a type such as int. That would be used where
other parts of the code (e.g. index variables) require that the size
be representable as an int so the code would break anyway if it isn't. You
are no better off using a "true" ssize_t in that respect because even that
isn't guaranteed to be able to represent all possible object sizes. C
allows the range of an unsigned integer type to be significantly larger
than the positive range of the corresponding signed type (not just approx.
double the size), so IMO ssize_t isn't a particularly useful concept.
(intmax_t)sizeof(e) in unacceptable because it potentially
extends the size and changes the semantics of the surrounding expression
as in
sizeof(sizeof(e)) != sizeof((intmax_t)sizeof(e))
When is this likely to be a problem in real code? If you want
sizeof(size_t) then write that, or ssizeof(size_t) or intsizeof(size_t) or
whatever.
I advocate casting to (signed) as a lone adjective should do this, but
it is incompatible with current C99 semantics that specify (signed) to
be quivalent to (signed int).
What is your version ?
Cast to the type of the signed variable or quantity the result will be
used with, probably. If your problem is selecting a suitable type for that
then you have to resort to the alternatives above.
There is no universally perfect solution to this, and that includes a
"true" ssize_t type. I'm happy to use size_t for my index variables and
deal with/avoid the fairly clear cut issues that arise from that. If you
have to count backwards (which is the minority of cases) you can use code
like
for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
or
size_t i = sizeof x;
while (i-- != 0)
or
for (size_t i = sizeof x; i != 0; ) {
i--;
...
}
Incidentally, this last approach also works naturally with pointers.
Lawrence
"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote: What is your version ?
Cast to the type of the signed variable or quantity the result will be
used with, probably. If your problem is selecting a suitable type for that
then you have to resort to the alternatives above.
that's not safe either :
int i;
....
i < (int)sizeof(x)
makes an explicit assumption about the type of i. It is not advisable.
For the very same reason 'p = malloc(sizeof(*p))' is safer than 'p =
malloc(sizeof(x))'.
If the type of i is later changed to long to accomodate for larger size_t, the
cast can go unnoticed and create very hard to find bugs.
There is no universally perfect solution to this, and that includes a
"true" ssize_t type. I'm happy to use size_t for my index variables and
deal with/avoid the fairly clear cut issues that arise from that. If you
have to count backwards (which is the minority of cases) you can use code
like
for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
Horrible, and probably relies on undefined behavior.
or
size_t i = sizeof x;
while (i-- != 0)
It is bad practice to call i something that is not an int, because a lot of
programmers will infer the wrong type in later expressions.
or
for (size_t i = sizeof x; i != 0; ) {
i--;
...
}
i > 0 works as well and is more natural.
Incidentally, this last approach also works naturally with pointers.
Agreed! Yet I would use > as well for pointers for the sake of readability.
--
Chqrlie.
Charlie Gordon wrote: "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k...
On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote:
What is your version ?
Cast to the type of the signed variable or quantity the result will be
used with, probably. If your problem is selecting a suitable type for that
then you have to resort to the alternatives above.
that's not safe either :
int i;
...
i < (int)sizeof(x)
makes an explicit assumption about the type of i. It is not advisable.
For the very same reason 'p = malloc(sizeof(*p))' is safer than 'p =
malloc(sizeof(x))'.
If the type of i is later changed to long to accomodate for larger size_t, the
cast can go unnoticed and create very hard to find bugs.
Well, then make this
my_ssize_t i;
.....
i < (my_ssize_t)sizeof(x)
with my_ssize_t defined in a header file. There is no universally perfect solution to this, and that includes a
"true" ssize_t type. I'm happy to use size_t for my index variables and
deal with/avoid the fairly clear cut issues that arise from that. If you
have to count backwards (which is the minority of cases) you can use code
like
for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
Horrible, and probably relies on undefined behavior.
How so? sizeof x > 0, and the unsigned overflow of -1 is defined.
If you do not like the cast, you can leave it out. or
size_t i = sizeof x;
while (i-- != 0)
It is bad practice to call i something that is not an int, because a lot of
programmers will infer the wrong type in later expressions.
Hmmm, we are not talking about Fortran.
It is traditional to use i, j, ... for loop iteration, yes.
IMO, if someone infers from "i is used to iterate through the
loop" that i were an int, then this is his or her personal problem.
I am doing most of my loops through arrays (or storage accessed via
pointer) using size_t loop variables which, as often as not, are called
i, j, ... These may be declared just for the loop or at the beginning
of some block. or
for (size_t i = sizeof x; i != 0; ) {
i--;
...
}
i > 0 works as well and is more natural.
Indeed. However, as you were referring to traditions:
This may help reminding the "i is always int" programmer that
we are dealing with i of type size_t :-) Incidentally, this last approach also works naturally with pointers.
Agreed! Yet I would use > as well for pointers for the sake of readability.
Umh, I am not sure whether you and Lawrence are referring to the
same sort of loop with pointers.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.
Lawrence Kirby wrote: On Wed, 15 Dec 2004 21:37:13 -0800, James Dennett wrote:
...
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
But getting to *improve* your style because of viable compiler
diagnostics is a fine opportunity, no?
That depends on whether you consider cluttered to be a better style than
keeping it simple.
I don't. But I consider type mismatches to be a failure
to keep things simple. Simplicity, true simplicity, is
very valuable in programming, and surprisingly hard to
achieve.
There is a legitimate issue that the compiler is
warning about, but it doesn't occur in this case and it is easy to see
that.
Special cases are a form of complexity too. In the end,
though, this is a very small issue, reasonable people can
disagree on their assessments of what is better.
-- James
In article <cp**********@reader1.imaginet.fr>, "Charlie Gordon" <ne**@chqrlie.org> writes: "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k...
for (size_t i = sizeof x; i != 0; ) {
i--;
...
}
i > 0 works as well and is more natural.
Where in nature does "i > 0" occur?
You may prefer it, but it is nothing more than a preference. Spare
us the bogus claims about what is "natural" C syntax.
Personally, I'd be just as happy with a plain "i" for the second "for"
expression. I know what it means; any competent C programmer knows
what it means; someone learning C either knows what it means or needs
to learn; no one else should be reading the code.
--
Michael Wojcik mi************@microfocus.com
Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".
On Thu, 16 Dec 2004 21:49:31 +0100, Charlie Gordon wrote: "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote: > What is your version ?
Cast to the type of the signed variable or quantity the result will be
used with, probably. If your problem is selecting a suitable type for that
then you have to resort to the alternatives above.
that's not safe either :
int i;
...
i < (int)sizeof(x)
makes an explicit assumption about the type of i. It is not advisable.
For the very same reason 'p = malloc(sizeof(*p))' is safer than 'p =
malloc(sizeof(x))'.
If the type of i is later changed to long to accomodate for larger size_t, the
cast can go unnoticed and create very hard to find bugs.
Whenever you cast you have to make sure the cast has the right type. Where
there is a way to avoid it then great but where there isn't you just have
to make do. There isn't an equivalent to sizeof(*p) available here. The
best you can do is a typedef used for the definition of i and the cast,
which may be reasonable in some contexts. There is no universally perfect solution to this, and that includes a
"true" ssize_t type. I'm happy to use size_t for my index variables and
deal with/avoid the fairly clear cut issues that arise from that. If you
have to count backwards (which is the minority of cases) you can use code
like
for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
Horrible, and probably relies on undefined behavior.
It is a normal, well known and portable idiom for getting the largest
value an unsigned integer type can represent. In this case the loop
condition also works if the type happens to be signed. You could hide the
details behind a macro if you wanted but I don't really see the need. or
size_t i = sizeof x;
while (i-- != 0)
It is bad practice to call i something that is not an int, because a lot
of programmers will infer the wrong type in later expressions.
I associate i more with "index" than "int" here. If you prefer to change
the variable name feel free. or
for (size_t i = sizeof x; i != 0; ) {
i--;
...
}
}
i > 0 works as well and is more natural.
How so? Incidentally, this last approach also works naturally with pointers.
Agreed! Yet I would use > as well for pointers for the sake of
readability.
I'd stick to != because it shows clearly that i had to hit a value exactly
for the loop to terminate. Seeing > somebody might be led to believe that
the test would still work if you skipped some values. != more accurately
describes the situation which makes it more readable in this case.
Lawrence Da*****@cern.ch (Dan Pop) writes: In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
Doing a Google Groups search with "-W" and "unsigned", and limiting
the time to Jan 1, 2003, to the present (and in comp.lang.c and with
da*****@cern.ch as author) yielded 11 hits. None of these contained
any substantive discussion of different -W options.
There is only one "-W" option as far as I know.
Sorry that this description was unclear. The word "constructs"
or "events" (which is gcc's choice, not mine) might have been
better. I meant the different code conditions that -W flags,
something like the following:
-W Print extra warning messages for these events:
o A function can return either with or without a
value.
o An expression-statement or the left-hand side of a
comma expression contains no side effects.
o An unsigned value is compared against zero with <
or <=.
o A comparison like x<=y<=z appears;
o Storage-class specifiers like "static" are not the
first things in a declaration.
o The return type of a function has a type qualifier
such as "const".
o A comparison between signed and unsigned values
could produce an incorrect result when the signed
value is converted to unsigned. (But don't warn
if -Wno-sign-compare is also specified.)
o An aggregate has a partly bracketed initializer.
o An aggregate has an initializer which does not
initialize all members.
Based on your comments below it's only the signed/unsigned comparison
that you object to. Is that right or are there others? For the
sake of discussion let's assume the above list gives the conditions
flagged by -W.
And my main objection
to it is that I get the following kind of warnings:
fangorn:~/tmp 127> cat test.c
int main()
{
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
that cannot be shut up without using a programming style I do not like
(either use of unnecessary casts or proliferation of unsigned variables).
I agree that these conditions can be annoying. I do consider them
useful however, both because of potentially incorrect results, and
because of the rules for how signs are dealt with in integral
promotions is one of the few areas where ANSI is at odds with many
(most?) pre-ANSI compilers; I think it helps to raise consciousness
about that. (The ANSI decision to use "value preserving" rather than
"signedness preserving" as the semantics for these promotions was not,
IMO, the best choice; but whether it's a good choice or not is
incidental to considering the warning useful.)
It's nice to see that the comments about the signed/unsigned warning
condition has generated some good discussion further along this
thread.
Of course, I could disable this specific warning with -Wno-sign-compare
but I can't find enough value in what's left to justify bothering with
baroque sequences of -W... options.
Your regular compilation environment must be different from mine. I
hardly ever either type in or see any of the various compiler flags
that are set for essentially all compilations I do. So even if the
benefit were small, in my environment it would be worth the investment
which is essentially zero.
OTOH, I couldn't find any objectionable warning generated by -Wall when
dealing with correct code. In all cases, shutting such warnings up
results in code whose correctness is clearer than before. -Wall also
helped me get rid of the "implicit int in function definitions" habit
inherited from the K&R C days.
Certainly I agree that many or most -Wall warnings are worth
getting rid of, with the particular case of implicitly 'int'
function being one of them.
So, what's wrong with -Wall, from your point of view?
Ok, the $64 question. Again for the sake of discussion let's take
the list below as the set of warnings covered by -Wall:
-Wchar-subscripts - using values of type 'char' to subscript
-Wcomment - when /* appears in a comment string (& more)
-Wformat - check printf et al format strings against args
-Wnonnull - NULL arg to "nonnull" attribute parameters
-Wimplicit - decl w/o type, or function call w/o decl
-Wmain - type of main() is suspicious
-Wmissing-braces - initializers not fully bracketed
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wsequence-point - possible violations of sequence point rules
-Wreturn-type - non-void function 'return;'; no function type
-Wswitch - switch( ENUM ) that doesn't cover all cases
-Wswitch-default - switch() w/o 'default:' case
-Wswitch-enum - switch( ENUM ) cases != ENUM values
-Wtrigraphs - if any trigraphs are encountered
-Wunused - unused variable, value, label, static function
-Wunused-parameter - unused parameter
-Wuninitialized - variable might be used without having been set
-Wunknown-pragmas - unrecognized #pragma
-Wstrict-aliasing - code that may break with -fstrict-aliasing
I realize this set probably doesn't exactly match the gcc that anyone
is currently using, but I think it will help the discussion if we
proceed under the assumption that these conditions make up the current
set of -Wall conditions.
I would break these down into four categories - the always useful, the
usually useful, the probably useful, and the objectionable.
The 'always useful' are those that simply never get turned off (that
is, in my environment). These conditions are ones I consider
synonymous with errors. (Normally I expect -Werror will be set [1]
whether the compilation is a "development" compilations or a
"production" compilation.) The always useful ones are:
-Wchar-subscripts - using values of type 'char' to subscript
-Wformat - check printf et al format strings against args
-Wmain - type of main() is suspicious
-Wreturn-type - non-void function 'return;'; no function type
The 'usually useful' are those that are on by default in production
code but could be turned off during development or sometimes on a
case-by-case basis for production compiles in unusual circumstances.
An example is the setting for the -Wtrigraphs condition - usually code
should have no trigraphs but sometimes it needs to, and -Wtrigraphs
needs to be disabled in those cases. The usually useful ones are:
-Wimplicit - decl w/o type, or function call w/o decl
-Wcomment - when /* appears in a comment string (& more)
-Wmissing-braces - initializers not fully bracketed
-Wswitch - switch( ENUM ) that doesn't cover all cases
-Wtrigraphs - if any trigraphs are encountered
-Wunused - unused variable, value, label, static function
-Wunused-parameter - unused parameter
-Wuninitialized - variable might be used without having been set
The 'probably useful' are those that most likely in one of the
previous two categories but I don't have enough specific experience
with them to give an opinion as to which. Operationally they are
treated just as the 'usually useful' ones are. The probably useful
ones are:
-Wnonnull - NULL arg to "nonnull"-attributed parameters
-Wsequence-point - possible violations of sequence point rules
-Wswitch-enum - switch( ENUM ) cases != ENUM values
-Wunknown-pragmas - unrecognized #pragma
-Wstrict-aliasing - code that may break with -fstrict-aliasing
The 'objectionable' are those that might get used as diagnostic tools
from time to time but are turned off during all regular compiles. The
objectionable ones are:
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wswitch-default - switch() w/o 'default:' case
Discussion for -Wswitch-default:
-Wswitch-default
Warn whenever a "switch" statement does not have a
"default" case.
First of all, either -Wswitch or -Wswitch-enum seems like a more
accurate diagnostic tool when the switch() expression is of an
enumerated type [2].
Second, the decision to put in a 'default:' case is a programming
practice that is appropriate in some circumstances but not in others.
Apparently there is no way to locally override the warning for
switch() statements where the 'default:' is judged better left out.
Third, automatically adding a 'default:' to every switch() can reduce
the value of -Wswitch/-Wswitch-enum. It can be useful to leave off
the 'default:' so that when additional values are added to an
enumerated type then switch() statements on values of that type will
be flagged. Including -Wswitch-default will thwart this programming
practice.
Discussion for -Wparentheses:
-Wparentheses
Warn if parentheses are omitted in certain contexts,
such as when there is an assignment in a context where
a truth value is expected, or when operators are
nested whose precedence people often get confused
about.
Also warn about constructions where there may be con-
fusion to which "if" statement an "else" branch
belongs. [Example/explanation omitted.]
First, this warning covers several rather different conditions lumped
together under a single name. The different conditions should have
been broken out under separately invokable switches.
Second, the several conditions are essentially different because they
protect against different kinds of error causes. The reason for
writing 'if((x=a+b))' rather than 'if(x=a+b)' is to show that it
wasn't a mistype for 'if(x==a+b)'. The case with extra parentheses
inside expressions is different - here the concern is not that
mistyping might have occurred but that a non-expert reader might be
confused about precedence. (Curiously, the 'if((x=a+b))' form is
"more clear" only *after* reaching a certain level of experience.)
The case with braces for unpaired if's is different in still another
way - here the concern is any reader might be mislead (possibly after
future editing) by other formatting cues to mis-perceive the actual
structure. ([3]) They do have something in common: to some
extent they all reflect "style choices".
Third, as it happens the style choice about bracing to help with
unpaired if's is one I agree with. I expect I would set this warning
condition (as a 'usually useful' one) if it were separately available.
Fourth, the style choice to add redundant parentheses in certain
circumstances is one I disagree with. To say that another way, I
might choose to add redundant parentheses under some circumstances,
but the developer should make the choice about when, not the compiler.
Fifth, encouraging putting in redundant parentheses sends the wrong
message. In effect, we're telling developers that they needn't bother
learning the different levels of precedence because no one else knows
them either. This (probably unintended) side-effect of -Wparentheses
is especially harmful in novices, affected at a time when they are
most impressionable.
Sixth, adding redundant parentheses to correct "mistakes" flagged
under -Wparentheses develops bad programming habits. Clearly the code
'if((x=a+b))' does exactly the same thing as 'if(x=a+b)', but we have
to put in the extra parentheses "to shut up the compiler". So the
presence of -Wparentheses messages dilutes the effect of other warning
conditions, which are more likely to require code changes that
are substantive rather than just cosmetic.
Finally, a comment about -Wall generally and not about any specific
flag -W<xxx> on the list.
The set of -W<xxx> in -Wall tends to grow over time. This is
important because code that compiles today (or, on platform X) might
not compile tomorrow (or on platform Y). Because I work on source
that is distributed in bundles that include warning flag settings for
compilation directives (usually in makefiles), I've learned to avoid
using -Wall since its meaning in the target environment might very
well be different than the meaning of -Wall in the originating
environment. To a certain extent the same thing is true of individual
warning condition sets, but these happen on a smaller scale. The
set of conditions flagged by -Wall can increase drastically.
What's the word for this again? Oh yes, it's "innovation". :)
So there's my $64 answer. (Braces himself for the rebuttals
sure to follow...)
Notes:
[1] To be more precise, I normally try to act as though -Werror
were set whether it actually is or not.
[2] Whoever is writing gcc documentation should consult a dictionary
more often; there is no such word as "enumeral". (Authority:
several unabridged dictionaries.)
[3] Personally I think any developer who doesn't use braces in every
case where controlled statements are not on the same line as their
control keyword is at least mildly insane. But I digress.
Lawrence Kirby <lk****@netactive.co.uk> writes: On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
...
fangorn:~/tmp 127> cat test.c
int main()
int i;
for (i = 0; i < sizeof(int); i++) ;
return 0;
}
fangorn:~/tmp 128> gcc -W test.c
test.c: In function `main':
test.c:5: warning: comparison between signed and unsigned
...
A perfectly valid warning !
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
Whether the warning is dumb depends on what you think the compiler is
diagnosing. I consider it poor style to compare a signed value and an
unsigned value, both because the results can be surprising and because
it isn't always obvious when/where it happens. That the code happens
to produce the results I expect (and, since the 'for' loop has an
empty body, how could it not?) does not effect the presence of the
warning condition.
Related question - if the code were
int main(){
int i = 0;
if( 0 ){
i += i++;
}
return 0;
}
would you want no diagnostic on the 'i += i++;' line, since
after all it won't be executed?
Lawrence Kirby <lk****@netactive.co.uk> writes: On Wed, 15 Dec 2004 21:37:13 -0800, James Dennett wrote:
...
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
But getting to *improve* your style because of viable compiler
diagnostics is a fine opportunity, no?
That depends on whether you consider cluttered to be a better style than
keeping it simple. There is a legitimate issue that the compiler is
warning about, but it doesn't occur in this case and it is easy to see
that.
Your perception of what the issue is may not match the perceptions
of others; apparently doesn't for some people.
On the cluttered/simple comment - that depends on the metrics being
used to measure "cluttered" and "simple", and on the relative weights
of those metrics compared to other factors (such as "may cause
maintenance problems in the future"). It also depends on what you
suppose the resolution of the problem is; the code
int main(){
return 0;
}
removes the warning and also is simpler and less likely to cause
maintenance problems in the future (at least by my metrics) as
compared with the original.
"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Thu, 16 Dec 2004 21:49:31 +0100, Charlie Gordon wrote:
"Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co.u k... On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote:
> What is your version ?
There is no universally perfect solution to this, and that includes a
"true" ssize_t type. I'm happy to use size_t for my index variables and
deal with/avoid the fairly clear cut issues that arise from that. If you
have to count backwards (which is the minority of cases) you can use code
like
for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
Horrible, and probably relies on undefined behavior.
It is a normal, well known and portable idiom for getting the largest
value an unsigned integer type can represent. In this case the loop
condition also works if the type happens to be signed. You could hide the
details behind a macro if you wanted but I don't really see the need.
Not at all !
It is not well known, and it is not portable.
Furthermore, it is not reliable : it is blatant undefined behaviour (because of
integer overflow).
(size_t)-1 is not necessarily the largest value size_t can represent : just
think of the different representations C99 allows for integer arithmetic. It
may work for 2's complement, doesn't work for 1's complement (off by one), and
completely wrong for sign/magnitude.
This loop is horrible, it should be banned. I rest my case.
--
Chqrlie.
In article <cq**********@reader1.imaginet.fr>, Charlie Gordon
<ne**@chqrlie.org> writes "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
news:pa****************************@netactive.co. uk... On Thu, 16 Dec 2004 21:49:31 +0100, Charlie Gordon wrote:
> "Lawrence Kirby" <lk****@netactive.co.uk> wrote in message
> news:pa****************************@netactive.co.u k...
>> On Thu, 16 Dec 2004 13:36:22 +0100, Charlie Gordon wrote:
>> > What is your version ?
>> There is no universally perfect solution to this, and that includes a
>> "true" ssize_t type. I'm happy to use size_t for my index variables and
>> deal with/avoid the fairly clear cut issues that arise from that. If you
>> have to count backwards (which is the minority of cases) you can use code
>> like
>>
>> for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
>
> Horrible, and probably relies on undefined behavior.
It is a normal, well known and portable idiom for getting the largest
value an unsigned integer type can represent. In this case the loop
condition also works if the type happens to be signed. You could hide the
details behind a macro if you wanted but I don't really see the need.
Not at all !
It is not well known,
Cannot comment and it is not portable.
It is about as portable as you can get.
Furthermore, it is not reliable : it is blatant undefined behaviour (because of
integer overflow).
size_t is required to be an unsigned type and there is no undefined
behaviour for overflow for unsigned integer types.
(size_t)-1 is not necessarily the largest value size_t can represent
It is required to be by the C and the C++ Standards. There is absolutely
no options.
: just
think of the different representations C99 allows for integer arithmetic.
Completely irrelevant, because those options are only applicable to
signed integer types and both C and C++ specify exactly how an out of
range value for an unsigned integer type must be converted into an in
range value.
It
may work for 2's complement, doesn't work for 1's complement (off by one), and
completely wrong for sign/magnitude.
This loop is horrible, it should be banned. I rest my case.
It would be a good idea to learn a little more C before condemining the
code of others.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
On Mon, 20 Dec 2004 12:30:01 +0100, Charlie Gordon wrote:
.... >> for (size_t i = (sizeof x)-1; i != (size_t)-1; i--)
>
> Horrible, and probably relies on undefined behavior.
It is a normal, well known and portable idiom for getting the largest
value an unsigned integer type can represent. In this case the loop
condition also works if the type happens to be signed. You could hide the
details behind a macro if you wanted but I don't really see the need.
Not at all !
It is not well known, and it is not portable.
I accept that I am only going on personal experience for the "well known"
bit and that may not be representative. If it isn't that is a pity. As for
your claim of non-portability it is just plain wrong, both in terms of
what the standard requires and, again in my experience, the lack of real C
compilers that are broken in this respect.
Furthermore, it is not reliable : it is blatant undefined behaviour (because of
integer overflow).
There is no integer overflow here. The rules for conversion from
any integer type to an unsigned integer type define clearly what happens
when the value being converted is not in the range of values representable
by the target type. It is never undefined.
(size_t)-1 is not necessarily the largest value size_t can represent :
It is easy to show from the rules in the standard that it must be.
just
think of the different representations C99 allows for integer arithmetic. It
may work for 2's complement, doesn't work for 1's complement (off by one), and
completely wrong for sign/magnitude.
Representation is irrelevant, the results of casts are defined in terms of
values NOT representations. If the result has a different bit pattern,
e.g. on a 1's complement architecture, the compiler must generate code
that makes the appropriate changes.
This loop is horrible, it should be banned. I rest my case.
Your case is based on incorrect assumptions. The C99 Standard says:
"When a value with integer type is converted to another integer type other
than _Bool, if the value can be represented by the new type, it is
unchanged.
Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that can
be represented in the new type until the value is in the range of the new
type."
So if we convert the *value* -1 to an unsigned type the value isn't
representable directly in the new type so we apply the 2nd paragraph to
find out what to do. We can add one more than the maximum value that can
be represented by the unsigned type i.e. mathematically
-1 + (MAX_VALUE_OF_NEW_TYPE+1), which reduces to MAX_VALUE_OF_NEW_TYPE.
This is in the range of the new type so we are finished, bar noting that
size_t is defined as an unsigned integer type so this analysis applies to
the for() loop above.
The C90 wording is different but the result is the same.
Lawrence
On Sat, 18 Dec 2004 15:32:20 -0800, Tim Rentsch wrote: Lawrence Kirby <lk****@netactive.co.uk> writes:
On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
...
>> fangorn:~/tmp 127> cat test.c
>> int main()
>>
>
>> int i;
>>
>> for (i = 0; i < sizeof(int); i++) ;
>> return 0;
>> }
>> fangorn:~/tmp 128> gcc -W test.c
>> test.c: In function `main':
>> test.c:5: warning: comparison between signed and unsigned
...
> A perfectly valid warning !
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
Whether the warning is dumb depends on what you think the compiler is
diagnosing. I consider it poor style to compare a signed value and an
unsigned value, both because the results can be surprising and because
it isn't always obvious when/where it happens. That the code happens
to produce the results I expect (and, since the 'for' loop has an
empty body, how could it not?) does not effect the presence of the
warning condition.
It isn't up to the compiler to impose style considerations on the
programmer. It is dumb because a less dumb compiler could easily prove
that in this case i can never be negative so "surprising" results simply
can't happen, on any conforming C implementation. So there aren't even
portability issues.
Related question - if the code were
int main(){
int i = 0;
if( 0 ){
i += i++;
}
return 0;
}
would you want no diagnostic on the 'i += i++;' line, since
after all it won't be executed?
I have no problem with a diagnostic on that, although most compilers don't
diagnose i+=i++ anywhere. i+=i++ is a bug if it gets executed and serves
no purpose if it can never be executed. There is no circumstance under
which it can be correct and sensible. That makes it quite different to the
loop example.
Lawrence
Lawrence Kirby wrote: On Sat, 18 Dec 2004 15:32:20 -0800, Tim Rentsch wrote:
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Tue, 14 Dec 2004 21:06:09 +0100, Charlie Gordon wrote:
...
> fangorn:~/tmp 127> cat test.c
> int main()
>
> int i;
>
> for (i = 0; i < sizeof(int); i++) ;
> return 0;
> }
> fangorn:~/tmp 128> gcc -W test.c
> test.c: In function `main':
> test.c:5: warning: comparison between signed and unsigned
...
A perfectly valid warning !
True, except when the code is clearly correct. Having to compromise your
progrmming style due to dumb compiler diagnostics is a problem.
Whether the warning is dumb depends on what you think the compiler is
diagnosing. I consider it poor style to compare a signed value and an
unsigned value, both because the results can be surprising and because
it isn't always obvious when/where it happens. That the code happens
to produce the results I expect (and, since the 'for' loop has an
empty body, how could it not?) does not effect the presence of the
warning condition.
It isn't up to the compiler to impose style considerations on the
programmer.
To issue a warning doesn't impose things on you. It gives you
information you can choose to act on, or choose not to act on.
It is dumb because a less dumb compiler could easily prove
that in this case i can never be negative so "surprising" results simply
can't happen, on any conforming C implementation. So there aren't even
portability issues.
I think it's reasonable for compilers to warn when you use error-prone
styles, even if they don't trigger errors in a given situation. YMMV.
-- James
On Tue, 21 Dec 2004 18:24:58 -0800, James Dennett wrote:
.... It isn't up to the compiler to impose style considerations on the
programmer.
To issue a warning doesn't impose things on you. It gives you
information you can choose to act on, or choose not to act on.
In practice people want to produce code that compiles without warnings.
There may even have to work under policies where this is the case. In
practical terms having a compilation generate a buch of spuious warnings
can easily obscure a serious one, and make it more difficult to pinpoint
where the start of the trouble is. It is dumb because a less dumb compiler could easily prove that in this
case i can never be negative so "surprising" results simply can't
happen, on any conforming C implementation. So there aren't even
portability issues.
I think it's reasonable for compilers to warn when you use error-prone
styles, even if they don't trigger errors in a given situation. YMMV.
Do you allow production code to compile with warnings?
Lawrence
On Wed, 22 Dec 2004 13:13:26 +0000, Lawrence Kirby wrote:
In practice people want to produce code that compiles without warnings.
That's pretty easy to do, wouldn't you say?
There may even have to work under policies where this is the case. In
practical terms having a compilation generate a buch of spuious warnings
can easily obscure a serious one, and make it more difficult to pinpoint
where the start of the trouble is.
It's often in the nature of these things that only a human can determine
what is a really serious warning. C is an unsafe language, and one has to
learn to live, somehow, with its lack of safety. If you want a safer
language, I could provide you with a whole list, but they all have their
drawbacks. What you lose on the swings, you gain on the roundabouts.
<snip>
Do you allow production code to compile with warnings?
Almost all the open-source software I build compiles with such warnings.
It seems to be a fact of life.
Alwyn
Lawrence Kirby wrote: On Tue, 21 Dec 2004 18:24:58 -0800, James Dennett wrote:
...
It isn't up to the compiler to impose style considerations on the
programmer.
To issue a warning doesn't impose things on you. It gives you
information you can choose to act on, or choose not to act on.
In practice people want to produce code that compiles without warnings.
There may even have to work under policies where this is the case. In
practical terms having a compilation generate a buch of spuious warnings
can easily obscure a serious one, and make it more difficult to pinpoint
where the start of the trouble is.
That's why we make code compile warning-free. Compilers usually
offer options to turn off particular warnings, if your house
style requires warning free compilation (as it should) but allows
styles which trigger warnings with a given compiler. It is dumb because a less dumb compiler could easily prove that in this
case i can never be negative so "surprising" results simply can't
happen, on any conforming C implementation. So there aren't even
portability issues.
I think it's reasonable for compilers to warn when you use error-prone
styles, even if they don't trigger errors in a given situation. YMMV.
Do you allow production code to compile with warnings?
No. But then I find that the natural style of most people
with whom I work doesn't tend to trigger warnings, except
sometimes when working with MSVC++6 where the standard headers
generate warnings which have to be #pragma'd off.
-- James
Lawrence Kirby wrote: On Tue, 21 Dec 2004 18:24:58 -0800, James Dennett wrote:
<snip>
I think it's reasonable for compilers to warn when you use error-prone
styles, even if they don't trigger errors in a given situation. YMMV.
Do you allow production code to compile with warnings?
Sometimes, yes. Some constructs cause the compiler to issue a warning
under circumstances where the code may, or may not, be safe. To give
a simple example, some compilers will warn against this code:
#include <stdlib.h>
int rnd_in_range(int low, int high)
{
int range = high + 1 - low;
double d = range * (rand() / (RAND_MAX + 1.0));
return d + low;
}
The warning is, of course, that significant information might
be lost when a double is converted to an int return value.
Under these circumstances, I have several options:
1) I can silence the warning with a cast, but that's never a good
idea.
2) I can turn that warning off globally, but then I will not be
warned when I *accidentally* lose significant information via
such a conversion.
3) I can litter my code with compiler-specific pragmas to turn
warnings on and off as required, but then I'm either nailed
to one compiler or forced to do a lot of #ifdef-ing.
4) I can put up with the warning, adding a comment to the code
to explain that *IN THIS CASE* the warning has been noted and
the code is known to be correct.
So yes, sometimes I let production code compile even with warnings.
I'd prefer not to, but sometimes it is the least of several evils.
On Wed, 22 Dec 2004 17:52:34 +0000, infobahn wrote: Lawrence Kirby wrote:
....
Do you allow production code to compile with warnings?
Sometimes, yes. Some constructs cause the compiler to issue a warning
under circumstances where the code may, or may not, be safe. To give
a simple example, some compilers will warn against this code:
#include <stdlib.h>
int rnd_in_range(int low, int high)
{
int range = high + 1 - low;
double d = range * (rand() / (RAND_MAX + 1.0));
return d + low;
}
The warning is, of course, that significant information might
be lost when a double is converted to an int return value.
Under these circumstances, I have several options:
1) I can silence the warning with a cast, but that's never a good
idea.
Never say never. Like goto, avoid it except where it is the best tool for
the job. A cast looks to me to be the sensible solution here.
1. Arithmetic casts aren't particularly dangerous, they don't allow you to
do things that you can't do with implicit conversions. Contrast that to
pointer casts which introduce numerous possibilities for undefined
behaviour.
2. If you use a cast then do comment it. A coding style that requires
EVERY cast to be justified in a comment would be perfectly reasonable.
2) I can turn that warning off globally, but then I will not be
warned when I *accidentally* lose significant information via such a
conversion.
Yes, the sledgehammer to crack a nut approach, The specifically targetted
cast is a much better solution, except perhaps in rare cases where you
have a lot of nuts to crack at once.
3) I can litter my code with compiler-specific pragmas to turn
warnings on and off as required, but then I'm either nailed to one
compiler or forced to do a lot of #ifdef-ing.
Messy, especially when there is a simple and clear solution that works on
all C compilers. By "works" I mean that the code is still correct and
portable. A cast of course isn't guaranteed to silence compiler warnings,
but I'm happy to ignore that problem until I encounter it.
4) I can put up with the warning, adding a comment to the code
to explain that *IN THIS CASE* the warning has been noted and the
code is known to be correct.
Then we have the problem of spurious compiler warnings hiding important
ones. And that isn't just different compiler warnings. What if you got a
"Significant information lost" warning indicating a real problem in
amongst all the spurious ones - would you spot it? You might just as well
disable the warning. The comment is OK, but it is better to comment
something local rather than getting the warning and then having to back
reference it to find the comment.
So yes, sometimes I let production code compile even with warnings. I'd
prefer not to, but sometimes it is the least of several evils.
IMO the warning is a bigger evil and alternatives such as casting are,
no can be, lesser evils than you make out.
Lawrence
Lawrence Kirby <lk****@netactive.co.uk> wrote: On Wed, 22 Dec 2004 17:52:34 +0000, infobahn wrote:
#include <stdlib.h>
int rnd_in_range(int low, int high)
{
int range = high + 1 - low;
double d = range * (rand() / (RAND_MAX + 1.0));
return d + low;
}
The warning is, of course, that significant information might
be lost when a double is converted to an int return value.
Under these circumstances, I have several options:
1) I can silence the warning with a cast, but that's never a good
idea.
Never say never. Like goto, avoid it except where it is the best tool for
the job. A cast looks to me to be the sensible solution here.
True. And that's coming from me, who thinks spurious casts are like a
high-voltage sign on a penlight battery.
1. Arithmetic casts aren't particularly dangerous, they don't allow you to
do things that you can't do with implicit conversions. Contrast that to
pointer casts which introduce numerous possibilities for undefined
behaviour.
2. If you use a cast then do comment it. A coding style that requires
EVERY cast to be justified in a comment would be perfectly reasonable.
Make that every cast except those in calls to <ctype.h> functions, in
comparison functions for qsort() and friends, and null pointer casts in
variadic functions, and I'd quite agree.
Richard
Tim Rentsch wrote: Da*****@cern.ch (Dan Pop) writes:
[snip discussion about the pros and cons of gcc's -W and -Wall warning
options]
So, what's wrong with -Wall, from your point of view?
Ok, the $64 question. Again for the sake of discussion let's take
the list below as the set of warnings covered by -Wall:
-Wchar-subscripts - using values of type 'char' to subscript
-Wcomment - when /* appears in a comment string (& more)
-Wformat - check printf et al format strings against args
-Wnonnull - NULL arg to "nonnull" attribute parameters
-Wimplicit - decl w/o type, or function call w/o decl
-Wmain - type of main() is suspicious
-Wmissing-braces - initializers not fully bracketed
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wsequence-point - possible violations of sequence point rules
-Wreturn-type - non-void function 'return;'; no function type
-Wswitch - switch( ENUM ) that doesn't cover all cases
-Wswitch-default - switch() w/o 'default:' case
-Wswitch-enum - switch( ENUM ) cases != ENUM values
-Wtrigraphs - if any trigraphs are encountered
-Wunused - unused variable, value, label, static function
-Wunused-parameter - unused parameter
-Wuninitialized - variable might be used without having been set
-Wunknown-pragmas - unrecognized #pragma
-Wstrict-aliasing - code that may break with -fstrict-aliasing
I realize this set probably doesn't exactly match the gcc that anyone
is currently using, but I think it will help the discussion if we
proceed under the assumption that these conditions make up the current
set of -Wall conditions.
I would break these down into four categories - the always useful, the
usually useful, the probably useful, and the objectionable.
[snip]
The 'objectionable' are those that might get used as diagnostic tools
from time to time but are turned off during all regular compiles. The
objectionable ones are:
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wswitch-default - switch() w/o 'default:' case
Discussion for -Wswitch-default:
-Wswitch-default
Warn whenever a "switch" statement does not have a
"default" case.
First of all, either -Wswitch or -Wswitch-enum seems like a more
accurate diagnostic tool when the switch() expression is of an
enumerated type [2].
Second, the decision to put in a 'default:' case is a programming
practice that is appropriate in some circumstances but not in others.
Apparently there is no way to locally override the warning for
switch() statements where the 'default:' is judged better left out.
Third, automatically adding a 'default:' to every switch() can reduce
the value of -Wswitch/-Wswitch-enum. It can be useful to leave off
the 'default:' so that when additional values are added to an
enumerated type then switch() statements on values of that type will
be flagged. Including -Wswitch-default will thwart this programming
practice.
All good points. However, obviously "-Wswitch-default is included in
-Wall" from the gcc documentation means that -Wswitch-default is *not*
included in -Wall;p JK But in fact it seems to be the case that
-Wswitch-default is indeed not included in -Wall --- thankfully. Testing
it I get no warnings when using the -Wall flag while I get tons of
warnings when I explicitly add the -Wswitch-default flag.
Here is an old post to this thread that I made through google that
doesn't seem to show up in any of the non-google news-readers I use.
(Not that you missed much if you haven't received it;) http://groups-beta.google.com/group/...bce6900ea6d6e4
Daniel Vallstrom
Daniel Vallstrom <da**************@gmail.com> writes: Tim Rentsch wrote: Da*****@cern.ch (Dan Pop) writes:
[snip discussion about the pros and cons of gcc's -W and -Wall warning
options]
So, what's wrong with -Wall, from your point of view?
Ok, the $64 question. Again for the sake of discussion let's take
the list below as the set of warnings covered by -Wall:
-Wchar-subscripts - using values of type 'char' to subscript
-Wcomment - when /* appears in a comment string (& more)
-Wformat - check printf et al format strings against args
-Wnonnull - NULL arg to "nonnull" attribute parameters
-Wimplicit - decl w/o type, or function call w/o decl
-Wmain - type of main() is suspicious
-Wmissing-braces - initializers not fully bracketed
-Wparentheses - eg, if(x=a+b). also, some unpaired if's
-Wsequence-point - possible violations of sequence point rules
-Wreturn-type - non-void function 'return;'; no function type
-Wswitch - switch( ENUM ) that doesn't cover all cases
-Wswitch-default - switch() w/o 'default:' case
-Wswitch-enum - switch( ENUM ) cases != ENUM values
-Wtrigraphs - if any trigraphs are encountered
-Wunused - unused variable, value, label, static function
-Wunused-parameter - unused parameter
-Wuninitialized - variable might be used without having been set
-Wunknown-pragmas - unrecognized #pragma
-Wstrict-aliasing - code that may break with -fstrict-aliasing
[discussion of objectionable warnings snipped]
All good points. However, obviously "-Wswitch-default is included in
-Wall" from the gcc documentation means that -Wswitch-default is *not*
included in -Wall;p JK But in fact it seems to be the case that
-Wswitch-default is indeed not included in -Wall --- thankfully. Testing
it I get no warnings when using the -Wall flag while I get tons of
warnings when I explicitly add the -Wswitch-default flag.
Oh, the documentation for what conditions -Wall includes is wrong?
Please add that to my list of reasons not to use -Wall.
(Thank you Daniel for the followup.) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jhon smith |
last post by:
Hi,all,I was just wondering if I am likly to have any problems trying to
learn C from older books,I have some from the late 80`s,mid/late 90`s.
I am using Dev-C++ on the pc windows platform,But I...
|
by: David Van D |
last post by:
Hi there,
A few weeks until I begin my journey towards a degree in Computer
Science at Canterbury University in New Zealand,
Anyway the course tutors are going to be teaching us JAVA wth bluej...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
