Learning C with Older books ?.

[Alwyn]

[ ... ]

There was also *Software Tools* by Kernighan and Plauger,

Yes, but it's a non-sequiter -- both the original (Ratfor) and second
(Pascal) editions of the Software tools book were intended to be
portable to many different environments.

I thought it followed quite well, actually: the broadening of 'the Unix
approach' to include non-Unix platforms.

What makes _The UNIX Programming Environment_ significant is that it
was NOT intended to be portable at all. It was intended to target UNIX
and only UNIX, but now it applies about equally to nearly _all_ OSes
in wide use.

It doesn't apply to Microsoft Windows, surely, though I'm told there is a
limited sense in which that could be considered POSIX-compliant. Cygwin
doesn't count, as it is a deliberate attempt to recreate a Unix-like
environment on a foreign system in order to take advantage of open-source
tools and applications.

Yes -- I remember reading this when it was originally published. While
most of what he said was true, it seemed to me quite an unbalanced view
at best.

Of course it is tendentious, but since I see this as an essay rather than
an academic paper, I find this an asset rather than a liability. It gives
us a highly readable insight into the mind of Brian W. Kernighan.

Looking at it again today, I'm even less impressed. Just for example, he
notes that Pascal's type definitions, such as:

type x = integer;
y = integer;

didn't produce truly new types -- you could mix arithmetic on x's and
y's and normal integers.

I took that as more of an observation than a criticism, though.

At the time, this was more or less a moot point, as C lacked any analog
to type definitions. When C added typedefs, however, they worked
essentially the same way as Pascal's type definitions.

Arguably the winner of this argument was Ada, which allows both the
Pascal/c style type definitions (where the new name is basically just
short-hand) but also has the ability to define a new type based on a
base type, but entirely separate from it.

Yes, and in Haskell:

type MyType = Int

makes 'MyType' a synonym for 'Int'; wherever I could write 'Int', I can
now write 'MyType'.

But I can also write:

newtype MyType' = IntNum Int

in which case I have created a whole new type which happens to have the
same representation as 'Int'. I now have work to do to give 'MyType''
acceptable behaviour, probably by making it an instance of class 'Num' and
defining the operators '+', '-', '*' etc. for it.

Anyway, thanks for the reminder of a simpler time; language wars
remain, but most of the issues have changed a LOT.

Well yes, the discourse has inevitably moved on, though many of the old
controversies and misconceptions remain; few questions have been
definitively resolved, and there is little in the way of consensus.


Alwyn

 

[JeffS]

Crap, clearly crap! One half, the standard itself is outated. The
other half is crap.
Schildt is unable to read and understund what is clearly written - so
his interpretation of the standard is crappy and useless.

I've no meaning to the other books - except: when a book is titled
"....C++..." it has nothing to do with C, it speaks about a completely
other language.

Get the C bible:
The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie.
Prentice Hall, Inc., 1988.
ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).

I agree on "The C Programming Language" being the best C tutorial and
reference and text book out there. I even think it's the best
programming book ever. I read it regularily, and do many of it's
exercises. It's helped me tremendously. This book is well worth the
$40 price. It's worth $400 for that matter.

However, if one is fairly new to programming and/or brand new to C, I
would hesitate making it the first book to get. A more simple
tutorial that is less terse and very easy to read is in order . For
example, Barnes and Noble has a series of books, called "In Easy
Steps". They cost $10, and give you the bare bones basics in an
extremely easy step by step tutorial. They have one for C of course.
Maybe get something like this first, then "The C Programming
Language".

As for C++, I would throw in "Accelerated C++", then "The C++
Programming Language" by Stroustrup.

"The C Programming Language", "The C++ Programming Language", along
with "Programming Windows - The definitive guide to the Win32 API" by
Charles Petzold, and finally "The Official Gnome 2 Developers Guide"
by Matthius Warkus rank as my all time favorite programming books.
These books helped me become a fairly competent C/C++ programmer
(along with coding of course), and the journey has been thoroughly
enjoyable.

As for Herb Schildt - While he is apparently guilty of technical
mistakes (not a good thing), I have to disagree with the "utter crap"
description put on him by the likes of Glassburrow and Rosenau and
others here. I have Schildt's "C++ The Complete Reference" third
addition, as well as his "Java The Complete Reference" fourth
addition. While having some mistakes (according to the gurus), these
books are outstanding in their presentation, samples, descriptions,
and prose. Herb Schildt really understands the perspective of the
newbie, and presents his material in easy to digest and understand
descriptions and examples. For this, Herb Schildt deserves major
kudos. For me, Schildt's books were good primers. I don't worry too
much about the supposed technical inaccuracies in these books, because
I get technical accuracy from K&R and Stroustrup. Plus, when you are
first learning, you are not going to remember all of the technical
details, so the mistakes are less costly.

I question whether Francis Glassborow or Herbert Rosenau truly
understand the perspective of the newbie.

 

[Tim Rentsch]

Only if you're forced to use a low quality compiler. The best lint-like
tool I've ever used is gcc. -Wall -O provide a decent set of "default"
checks that the programmer can easily extend according to his needs
(e.g. to check that all function declarations are prototype declarations).

It's funny - my experience with -Wall and -W apparently is the
opposite of some of the other folks here. I find -W extremely helpful
and have it on all the time, and -Wall to give too many unhelpful or
anti-helpful messages for what it considers "style violations". I'm
absolutely ruthless about the warnings that -W produces (since I also
use -Werror). But -Wall hasn't been nearly as helpful.

Except for that I definitely agree with Dan's comments.

Oh, while we're on this subject, I have a gripe about -Wtraditional.
It used to be (I don't know when this changed) that -Wtraditional
flagged only constructs that were legal in both K&R C and in ANSI C,
and had different meanings in K&R C and in ANSI C. Then at some point
the -Wtraditional started including warnings for things that were
legal in ANSI C but not in K&R C (notably including ANSI-style
function definitions). The result was that -Wtraditional went from
being something useful that I'd have on all the time to something
totally useless (at least, nearly totally useless for most purposes).
So I think someone hadn't eaten their Wheaties the morning of the
day they made *that* decision.

Ahhh... I feel much better now.

 

[Dan Pop]

It's funny - my experience with -Wall and -W apparently is the
opposite of some of the other folks here. I find -W extremely helpful
and have it on all the time, and -Wall to give too many unhelpful or
anti-helpful messages for what it considers "style violations". I'm
absolutely ruthless about the warnings that -W produces (since I also
use -Werror). But -Wall hasn't been nearly as helpful.

Well, you're also at odds with the gcc developers themselves. 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:

Dan

 

[Tim Rentsch]

Well, you're also at odds with the gcc developers themselves. 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:

At odds with the developers of gcc? Say it isn't so.

More seriously, I'm not sure what point you're trying to make. Using
-Wall flags a certain set of warning conditions (a set of -Wxxx, for
various xxx's); using -W flags a different set of warning conditions,
those shown following the "events:" text. Clearly neither set
contains the other.

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. Obviously that's not right, but let's skip that right now.
There's the little confusion that -Wall is "All of the above -W
options", whereas what they really mean is that -Wall is all of
the -W<whatever> options for each of the preceding -W<whatever>s.

The paragraph saying "The following -W... options are not implied by
-Wall. <I>Some</I> [my italics] of them warn about constructions
that users generally do not consider questionable..." doesn't
necessarily say anything about -W in particular; it does say
something about the collection of -W<x>'s following the paragraph
as a group, but not necessarily about any particular member of
the group (of which -W is one).

Even if -W is understood to be in the set that most users don't
consider questionable, that doesn't contradict my position, or mean
that my opinion and the opinion of the gcc developers are
incompatible. The set of -Wall conditions that I consider worth
flagging is a proper subset of the set of -Wall conditions that any
user might consider worth flagging; even though -W warns about
constructs that most users don't consider worth flagging, I do
consider them worth flagging. Again, ignoring the inconsistency that
if any user anywhere finds a particular warning construct questionable
then the documentation implies that a warning for that construct would
be included in -Wall.

Incidentally, note that the text of the gcc documentation included
here doesn't say anything about the opinions of the gcc developers
themselves about these warnings; it only says something about what
they consider the opinions of users.

For completeness I should add that some of the individual warnings
that make up the -Wall set I do find useful, and the useful ones get
turned on individually.

I realize that conventional wisdom says that -Wall is most helpful in
finding program problems, and -W less so. I'm reporting that in my
own experience the opposite has been true.

 

[Dan Pop]

At odds with the developers of gcc? Say it isn't so.

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, while the
warnings not included in -Wall are the controversial ones: some people
like, others don't, but, more importantly, avoiding them enforces a
certain programming style, which is something you don't normally want from
a compiler, unless you happen to like that particular programming style.

I've seen people advocating -Wall alone, people advocating -Wall -W and
people advocating all -W options. You're the first one saying that -W
is more valuable to you than -Wall. That's fine with me, but I'll
continue to avoid -W like the plague.

Using
-Wall flags a certain set of warning conditions (a set of -Wxxx, for
various xxx's); using -W flags a different set of warning conditions,
those shown following the "events:" text. Clearly neither set
contains the other.

And the quoted text explains the difference between the two sets.

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"? 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.

Obviously that's not right, but let's skip that right now.

Indeed, but the mistake is yours.

I realize that conventional wisdom says that -Wall is most helpful in
finding program problems, and -W less so. I'm reporting that in my
own experience the opposite has been true.

OK, what are the problematic warnings triggered by -Wall?

Dan

 

[Francis Glassborow]

I question whether Francis Glassborow or Herbert Rosenau truly
understand the perspective of the newbie.

Everyone is entitled to an opinion, but would you consider that a book
on electrical equipment by an author who did not understand the
difference between a live and a neutral wire to be an acceptable
introductory guide?

Perhaps you still do not understand how very bad Schildt's understanding
of C++ is coupled with his programming style being stuck in a time warp
circa 1985.

For the record, I was a teacher of teenagers for 30 years, and taught
programming across the entire academic spectrum (including to youngsters
who are variously described as 'non-academic', 'slow learners' etc.) So
I think I just might understand the needs of newbies a little better
than many (some of my colleagues considered that I was crazy to waste
time on pupils at the low end of the academic range.

Now as for the '...in Easy Steps' books, they have two advantages, they
are dirt cheap, and they make absolutely no demands on the reader's
intelligence. The disadvantage is that they will also teach the reader
nothing about programming only how to copy code from a book into an IDE.

 

[Gene Wirchenko]

(e-mail address removed) (JeffS) wrote:

[snip]

I get technical accuracy from K&R and Stroustrup. Plus, when you are
first learning, you are not going to remember all of the technical
details, so the mistakes are less costly.

I buy technical books for technical accuracy.

You are going to learn it wrong when you have less "common sense"
to detect such errors. Bad habits can be difficult to identify, let
alone get rid of.

I question whether Francis Glassborow or Herbert Rosenau truly
understand the perspective of the newbie.

As a newbie in any field, I want to know how to get it right. If
I want to go wrong, I have no need to spend money on books; I can do
it myself.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

 

[Tim Rentsch]

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.

??? 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 }

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.

Pretty clearly, what was intended by the gcc documentation is that the
warnings of -Wall include all the warnings for which there is some
substantial set of users that consider those constructs questionable.
But that isn't what was actually said.

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.

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.

 

[Daniel Vallstrom]

Actually, if you are using a recent version of gcc they suggest
using the equivalent "-Wextra" instead of "-W":

"-Wextra
(This option used to be called -W. The older name is still supported,
but the newer name is more descriptive.)"

That may be what they mean but it isn't what they say.

They do too!-) (IMO FWIW, more or less).

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!?! Do you have success applying the rules in daily
life?-)

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.

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.


[snip]

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


FWIW I too am on the gcc, DP, rest of the world side here. Sorry;p
However, I do find -W useful too and usually do use it in at least
makefiles.

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.

"-Wall:
-Wparentheses
Warn [...] when operators are nested whose precedence people
often get confused about."

While -Wparentheses enables many useful warnings, unfortunately it
also enables the braindead warning about use of && and ||. They
might just as well warn of the corresponding use of * and +, as
in "2*3 + 4". I can't believe that "people often get confused about"
&& and ||. For the warning to be helpful to a user, first the user
must not know the precedence, and then she must assume --- contrary
to reason --- that the wrong precedence holds.

At least there should be a flag that disabled the specific &&-||
warning but kept all the others. Now one has to use -Wno-parentheses
together with -Wall. And when one occasionally enables -Wparentheses
one has to filter away all the billion &&-|| warnings.

I have heard that the reason for the &&-|| warning is that the
person coding it in the first place (the good RMS?!) was influenced
by the cnf (conjunctive normal form) format. However, the cnf format
shouldn't be allowed to affect C's && and || in any way of course.
Besides, it is a misunderstanding of cnf since the cnf format is not

(p1||q1||...) && (p1||q2||...) && ...

but rather

&&{ ||{p1,q1,...}, ||{p2,q2,...}, ... }

with an implicit outermost && typically, and precedence doesn't
occur in cnf.

Bottom line is that you should all petition gcc to fix the
braindead &&-|| warning=)


-Wextra (-W) warns about the idiom

p0 == p1 == ... == pn

even when pi is 0 or 1, or of type bool. This is unfortunate.


While I agree that you normally shouldn't get any warnings, using
-Werror feels a bit over the top. With -Werror together with -W and
-Wall you get errors for unused arguments and variables, which often
happens during development.


Here are flags I commonly use. (It was some time ago though that I
compiled this list). Comments are welcome.

-std=c99 -pedantic \
-fstrict-aliasing \
-Wall \
-Wno-parentheses \
-Wformat-nonliteral \
-Wformat-security \
-Wformat=2 \
-Wunknown-pragmas \
-W \
-Wundef \
-Wshadow \
-Wpointer-arith \
-Wbad-function-cast \
-Wcast-qual \
-Wcast-align \
-Wno-sign-compare \
-Waggregate-return \
-Wstrict-prototypes \
-Wmissing-prototypes \
-Wmissing-declarations \
-Wredundant-decls \
-Wnested-externs \
-Wdisabled-optimization \


Daniel Vallstrom

 

[Tim Rentsch]

(e-mail address removed) (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".

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.

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.

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.

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.

 

[James Dennett]

(e-mail address removed) (Dan Pop) writes:




(e-mail address removed) (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.")

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.

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.

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.

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

 

[Dan Pop]

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

 

[Tim Rentsch]

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/logic/ch4-language-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.

 

[Tim Rentsch]

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.

 

[CBFalconer]

That's right, you were:


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

 

[Dan Pop]

That's right, you were:



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

 

[Tim Rentsch]

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.

 

[Dan Pop]

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

 

[Tim Rentsch]

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
(e-mail address removed) as author) yielded 11 hits. None of these contained
any substantive discussion of different -W options. About the closest
was this:


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.