By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,814 Members | 1,671 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,814 IT Pros & Developers. It's quick & easy.

Learning C with Older books ?.

P: n/a
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 #1
Share this Question
Share on Google+
90 Replies


P: n/a
Jhon smith wrote:
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.
certainly not, one of the best books is from the designer of c (Kernighan
and Ritchie) and that's an old book (mine is from 1990, the first edition
was from 1970 or so)
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.


Nov 14 '05 #2

P: n/a
[F'up2 cut down --- should have been done by OP!]

In comp.lang.c.moderated Jhon smith <jh**********@hotmail.com> wrote:
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.


Not really. You'll be missing out on the changes introduced by the
C99 standard, but that's not of very high practical relevance yet, and
can relatively easily be fixed up later. Stay away from any books
older than roughly 1990 though --- you don't want to learn
pre-standard C.

--
Hans-Bernhard Broeker (br*****@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #3

P: n/a
Jhon smith wrote:
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.


The book from 1988 might be a bit out-dated, unless it is a very
high-quality book, like the second edition of "The C Programming
Language".
The other books will do fine date-wise, but be warned that there are a
lot of bad books in circulation, regardless of when they were printed.
If you want to know if your books are any good, check if you can find a
review for them at http://www.accu.org/ or ask us (please tell us the
title, author(s) _and_ version of each book).

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #4

P: n/a
The core language has remained the same more or less.
Of course C++ was introduced which added a lot and changed things around as
well but for pure C that's not relevant.

There have also been some libraries added maybe which you will not learn
about but that's the extend of your potential shortcomings.

As a book you should certainly get: The C programming language by Kernighan
and Ritchie, creators of C.

"Jhon smith" <jh**********@hotmail.com> wrote in message
news:cl****************@plethora.net...
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

--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #5

P: n/a
Jhon smith wrote:
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.


There are some changes in the more recent C, but as long as your book
describes some version of ANSI/ISO C, it will be reasonably close. Older
(K&R) C books are likely to be more misleading. Check if it mentions
ANSI or ISO at the front of the book.

--
Ron House ho***@usq.edu.au
http://www.sci.usq.edu.au/staff/house
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #6

P: n/a
"Jeroen Wenting" <be*******@hornet.beefjerky.demon.nl> wrote in message news:<cl****************@plethora.net>...
The core language has remained the same more or less.
Of course C++ was introduced which added a lot and changed things around as
well but for pure C that's not relevant.

There have also been some libraries added maybe which you will not learn
about but that's the extend of your potential shortcomings.

As a book you should certainly get: The C programming language by Kernighan
and Ritchie, creators of C.

"Jhon smith" <jh**********@hotmail.com> wrote in message
news:cl****************@plethora.net...
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


As long as the book covers standard ANSI C you are fine. Check the
cover or the intro for that. The K&R ANSI C version is a good book to
use.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #7

P: n/a
Thanks for all,the help,I will look through the book review section on
ACCU,Thanks for that one.

"Jhon smith" <jh**********@hotmail.com> wrote in message
news:cl****************@plethora.net...
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

--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #8

P: n/a
HI all again,I just thought I give you a list of the books I have for you to
say yay or nay to as far as good learning tools.

I don`t know if it`s relevent,but I have a little machine code and assembler
experence from the old c64 days,I never really used basic,and have no real
experence of other languages,I don`t like being kept to far removed from the
machine,thats what i liked about the old MC/assem all those bit/byte opps.

I have looked at things like Pure basic,as as a start in PC programming,but
I like somthing about C,I hate the idea of great big fat programs,when it`s
not needed,however I am finding it a daunting task,as If I look on the net I
see reference to things,libarys,headers,API`s and many other things,Yet no
firm explanation of what is C,and what is purley added buy others,What is
needed to learn and what is at least for the time being,not nessesary.

With the `Basics` it seems much more defined,Learn the basic your
using,learn windows/hardware your using it on,Just with C I know where to
start,I just don`t know Which direction to go and howfar in that direction
to go.

My goal really is to learn C,then if Im upto it,more about using C on the PC
with MS windows(ie windows,graphics,sound),If I ever get that far,and
possibly C++.

The other BIG problem is that I am pretty damn thick,but I really would be
happy if all I can learn to do is simple apps,such a Phone book,with
input/output,disk loading/saving,sorting and such,But I don`t want to have a
basic language do it for me with a few commands,where`s the fun and thinking
in that!.

Any way enough ranting,Here`s my books.

C The complete reference---Herbert schildt first edition,1987
Simple C,Ian sinclair ---1988
Absolute beginners Guide to C,Greg Perry,second edition---1994
C++ Primer plus,Stephan prata,second edition---1995
Learning to program in C,N kantaris---Reprinted 1997
C/C++ Programmers bible Kris jamsa,Lars klander,first edition,---1998

Thanks again.
"Jhon smith" <jh**********@hotmail.com> wrote in message
news:cl****************@plethora.net...
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

--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #9

P: n/a
Jhon smith wrote:
HI all again,I just thought I give you a list of the books I have for you to
say yay or nay to as far as good learning tools. C The complete reference---Herbert schildt first edition,1987
Nay! See http://www.lysator.liu.se/c/schildt.html
Simple C,Ian sinclair ---1988
Absolute beginners Guide to C,Greg Perry,second edition---1994
C++ Primer plus,Stephan prata,second edition---1995
Learning to program in C,N kantaris---Reprinted 1997
C/C++ Programmers bible Kris jamsa,Lars klander,first edition,---1998


I don't remember these - check the ACCU book reviews at

http://www.accu.org/bookreviews/public/index.htm

Simple C isn't there.
Absolute Beginners Guide isn't there.
C++ Primer Plus 4th Edn is reviewed.
Learning to Program in C is reviewed.
C/C++ Programmer's Bible isn't there.

If you already program competently, then K&R is still very good.

--
Jonathan Leffler #include <disclaimer.h>
Email: jl******@earthlink.net, jl******@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #10

P: n/a
Jhon smith <jh**********@hotmail.com> scribbled the following
on comp.lang.c:
Any way enough ranting,Here`s my books. C The complete reference---Herbert schildt first edition,1987
You should consider dropping this book. Herbert Schildt is commonly
regarded as a bad author. His C books contain many mistakes.
Simple C,Ian sinclair ---1988
Absolute beginners Guide to C,Greg Perry,second edition---1994
C++ Primer plus,Stephan prata,second edition---1995
Learning to program in C,N kantaris---Reprinted 1997
C/C++ Programmers bible Kris jamsa,Lars klander,first edition,---1998 Thanks again.


--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"It sure is cool having money and chicks."
- Beavis and Butt-head
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #11

P: n/a
HI,
You should!!! buy the "C programming language" from Kernighan and Ritchie.
It's a must for everyone! An excellent book!

Ο "Jhon smith" <jh**********@hotmail.com> έγραψε στο μήνυμα
news:cl****************@plethora.net...
HI all again,I just thought I give you a list of the books I have for you to say yay or nay to as far as good learning tools.

I don`t know if it`s relevent,but I have a little machine code and assembler experence from the old c64 days,I never really used basic,and have no real
experence of other languages,I don`t like being kept to far removed from the machine,thats what i liked about the old MC/assem all those bit/byte opps.

I have looked at things like Pure basic,as as a start in PC programming,but I like somthing about C,I hate the idea of great big fat programs,when it`s not needed,however I am finding it a daunting task,as If I look on the net I see reference to things,libarys,headers,API`s and many other things,Yet no
firm explanation of what is C,and what is purley added buy others,What is
needed to learn and what is at least for the time being,not nessesary.

With the `Basics` it seems much more defined,Learn the basic your
using,learn windows/hardware your using it on,Just with C I know where to
start,I just don`t know Which direction to go and howfar in that direction to go.

My goal really is to learn C,then if Im upto it,more about using C on the PC with MS windows(ie windows,graphics,sound),If I ever get that far,and
possibly C++.

The other BIG problem is that I am pretty damn thick,but I really would be
happy if all I can learn to do is simple apps,such a Phone book,with
input/output,disk loading/saving,sorting and such,But I don`t want to have a basic language do it for me with a few commands,where`s the fun and thinking in that!.

Any way enough ranting,Here`s my books.

C The complete reference---Herbert schildt first edition,1987
Simple C,Ian sinclair ---1988
Absolute beginners Guide to C,Greg Perry,second edition---1994
C++ Primer plus,Stephan prata,second edition---1995
Learning to program in C,N kantaris---Reprinted 1997
C/C++ Programmers bible Kris jamsa,Lars klander,first edition,---1998

Thanks again.
"Jhon smith" <jh**********@hotmail.com> wrote in message
news:cl****************@plethora.net...
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

--
comp.lang.c.moderated - moderation address: cl**@plethora.net

--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #12

P: n/a
On Sun, 21 Nov 2004 03:50:27 UTC, "Jhon smith"
<jh**********@hotmail.com> wrote:
C The complete reference---Herbert schildt first edition,1987


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

In ideal you would get 3 books:
1. The book itself is known as C bible.
2. a book containing a collection of homeworks. They get pointed from
1)
when the books speaks about that theme. So you can work through the
book 1)
learn anything and use this book to train what you've learned.
3. a book containing all the solutions to 2). This book is good to
check your
personal results aginst the one the authors thinks you should
gotten.
As C is somewhat flexible you may still find another solution. But
it
would help to check aginst the obnes here anyway because you may
see
something you would not without. True learning means: use book 1)
to study, book 2) to get first practice about the chapter you're
studying
and thereafter book 3) to check your esults. Means hold 3) really
close until
youve done really what 2) asks - chapter for chapter.

Even as the C bible is NOT designed to be a tutotial in programming it
is a tutorial in programming C for anybody who had learned the
principes of programming in some way already. So with real programming
experience in e.g. assembly, COBOL, BASIC.... you should have no
problem to understund it. It is in some aspects outdated but anyway
good enough to understund what C is and how to use it.

ISO/IEC 9899:1999 is the current C standard. This is NOT a tutorial
but the base for programming in C of this century. It may be hard to
understund and ununderstandable for beginners it is a good reference
to learn how to program in C get your program independant of the
current used hardware and OS but easy portable to any other.

You should work through the standard AFTER you have learned the basics
as described in the C bible. Not any aspect will be really of interest
as normal programmer as the standard is designed to give all rules to
write a current C compiler - but when you knows about the requirements
to an C compiler you would have more understunding on how write
programs in C as the C compiler will dictate what is good, right and
functional.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #13

P: n/a
Jhon smith wrote:
HI all again,I just thought I give you a list of the books I have for you to
say yay or nay to as far as good learning tools.
I have looked at things like Pure basic,as as a start in PC programming,but
I like somthing about C,I hate the idea of great big fat programs,when it`s
not needed,however I am finding it a daunting task,as If I look on the net I
see reference to things,libarys,headers,API`s and many other things,Yet no
firm explanation of what is C,and what is purley added buy others,What is
needed to learn and what is at least for the time being,not nessesary. K&R, especially, start with a demonstration of just how simple C can be:
the "Hello, world!" program. The standard library is there to allow you
to write console apps easily and *portably*. C programs *can* be very
simple.
Any way enough ranting,Here`s my books.

C The complete reference---Herbert schildt first edition,1987 Not thought to be too good by some. See:
<http://herd.plethora.net/~seebs/c/c_tcr.html>
<http://catb.org/~esr/jargon/html/B/bullschildt.html>
Simple C,Ian sinclair ---1988 This and the previous are also most-likely out of date; the first real
ANSI C was the C89 standard, from 1989.
Absolute beginners Guide to C,Greg Perry,second edition---1994
C++ Primer plus,Stephan prata,second edition---1995
Learning to program in C,N kantaris---Reprinted 1997
C/C++ Programmers bible Kris jamsa,Lars klander,first edition,---1998 Don't mix C with C++. I recommend learning C first, then C++. They
generally use different I/O libraries, and have a different style, in
addition to the features in C that aren't in C++, as well as the converse.

BTW, don't top-post:
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--
Simon Richard Clarkstone
s.************@durham.ac.uk / s***************@hotmail.com
Eye half a spelling chequer / It came with my pea sea. /
It plane lee Marx for my reef-ewe / Miss takes eye can knot sea.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #14

P: n/a
In article <cl****************@plethora.net>, Jonathan Leffler
<jl******@earthlink.net> writes

I believe we recently weeded out reviews of very old books.
Simple C isn't there. I seem to remember that I was not impressed, it is also very old and
pre-ANSI C.
Absolute Beginners Guide isn't there.
Greg Perry does not have a good track record with me and read Yechiel
Kimchi's review of 'C by Example' to see that I am far from being alone
in that view.
C++ Primer Plus 4th Edn is reviewed.
Learning to Program in C is reviewed.
C/C++ Programmer's Bible isn't there.

The lead author of that book is also responsible for publishing it
(indirectly). The unfortunate result is that it has lacked the benefit
of an independent editor. Jamsa is definitely among those who know
considerably less than they think they do.

--
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #15

P: n/a
In article <cl****************@plethora.net>, Herbert Rosenau
<os****@pc-rosenau.de> writes
Get the C bible:
No it is normally called K&R, and calling it the C bible leads to
confusion with books that actually have that title.
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).


--
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #16

P: n/a
In article <cl****************@plethora.net>, mmmm <pa**@mland.gr>
writes
HI,
You should!!! buy the "C programming language" from Kernighan and Ritchie.
It's a must for everyone! An excellent book!


However be aware that it makes many implicit assumptions about the
programming environment. Quite a few early implementations of C were
based on this book with the result that necessary tool support (such as
lint) was unknown to many who learnt C by combining this book with a
compiler.

If you are already familiar with a Unix type development environment K&R
is excellent. If you are not, or are not using such an environment I am
less certain. There is a wealth of bad, dangerous C code (full of
undefined behaviour) written by people who relied on this book as their
sole source of information on programming (in C).
--
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #17

P: n/a
"Herbert Rosenau" <os****@pc-rosenau.de> writes:
On Sun, 21 Nov 2004 03:50:27 UTC, "Jhon smith"
<jh**********@hotmail.com> wrote:
C The complete reference---Herbert schildt first edition,1987


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.


You're thinking of Schildt's _The Annotated ANSI C Standard_, which
has a copy of the C90 standard on the left-hand pages and Schildt's
annotations on the facing pages. At one time, it was the cheapest way
to get a copy of (most of) the C90 standard, but the annotations are,
as you say, crap. Clive Feather reviews it at
<http://www.lysator.liu.se/c/schildt.html>.

_C: The Complete Reference_ is a different book by the same author. I
haven't read it, but according to Francis Glassborow's review at
<http://www.accu.org/bookreviews/public/reviews/c/c002173.htm>, it's
not as bad as _The Annotated ANSI C Standard_ (which is just about the
weakest possible praise).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #18

P: n/a
In article <cl****************@plethora.net>, pa*****@cc.helsinki.fi says...
Jhon smith <jh**********@hotmail.com> scribbled the following
on comp.lang.c:
Any way enough ranting,Here`s my books.

C The complete reference---Herbert schildt first edition,1987


You should consider dropping this book. Herbert Schildt is commonly
regarded as a bad author. His C books contain many mistakes.


I'd say you could go farther and say that not only is he a horrible
author or technical books, the scope of his abysmal mistakes extend
beyond just his books on C. In general, if his name is on the cover,
it's not worth even thumbing through, much less purchasing.

--
Randy Howard (2reply remove FOOBAR)
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #19

P: n/a
Francis Glassborow wrote:
If you are already familiar with a Unix type development environment K&R
is excellent. If you are not, or are not using such an environment I am
less certain. There is a wealth of bad, dangerous C code (full of
undefined behaviour) written by people who relied on this book as their
sole source of information on programming (in C).


I don't think that is much of a problem with the 2nd edition
(the "ANSI C" one). Your point that there is more to
software development than is explained in this one book is
valid, but then there doesn't seem to be *any* single book
that covers it all. Supplemental reading is therefore going
to be necessary, and at least K&R2 gives a reasonable picture
of the C language itself.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #20

P: n/a
In <cl****************@plethora.net> Francis Glassborow <fr*****@robinton.demon.co.uk> writes:
In article <cl****************@plethora.net>, mmmm <pa**@mland.gr>
writes
HI,
You should!!! buy the "C programming language" from Kernighan and Ritchie.
It's a must for everyone! An excellent book!
However be aware that it makes many implicit assumptions about the
programming environment. ^^^^^^^^


Haven't noticed any, so please elaborate.
Quite a few early implementations of C were ^^^^^based on this book with the result that necessary tool support (such as
lint) was unknown to many who learnt C by combining this book with a
compiler.
K&R1 mentions lint in several places. It is the C standard itself that
completely ignores it, so I fail to see your point.
If you are already familiar with a Unix type development environment K&R
is excellent. If you are not, or are not using such an environment I am
less certain.
I learned C from K&R1 years before getting my first Unix account. It was
(by far) the best programming language tutorial book I have ever read.
And the first implementation I have used was as Unix-unlike as you can
get (HiSoft C for the Sinclair ZX-Spectrum).
There is a wealth of bad, dangerous C code (full of
undefined behaviour) written by people who relied on this book as their
sole source of information on programming (in C).


Where they taught by the book to write such code?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #21

P: n/a
On Tue, 23 Nov 2004 21:05:57 +0000, Francis Glassborow wrote:
In article <cl****************@plethora.net>, mmmm <pa**@mland.gr>
writes
HI,
You should!!! buy the "C programming language" from Kernighan and Ritchie.
It's a must for everyone! An excellent book!
However be aware that it makes many implicit assumptions about the
programming environment.


Does it? I thought it only assumed a standard C compiler.
Quite a few early implementations of C were
based on this book
You mean on the first edition? That would be quite natural.
with the result that necessary tool support (such as
lint) was unknown to many who learnt C by combining this book with a
compiler.
I haven't got my copy to hand, but I do seem to recall that they mention
'lint'. Even so, I've never used it and would hardly call it a 'necessary
tool'.
If you are already familiar with a Unix type development environment K&R
is excellent. If you are not, or are not using such an environment I am
less certain.
That is your privilege, but it would be nice if you could justify your
opinion just a little bit.
There is a wealth of bad, dangerous C code (full of
undefined behaviour) written by people who relied on this book as their
sole source of information on programming (in C).


If you're talking about the first edition again, then maybe, just maybe,
since the definition of the language was necessarily somewhat fluid then.
But if you're talking about the edition with 'ANSI C' stamped in red on
the cover, then I am uncomprehending. I thought Kernighan and Ritchie had
always been *the* standard text on C.
Alwyn

Nov 14 '05 #22

P: n/a
In article <pa****************************@blueyonder.co.uk >, Alwyn
<al***@blueyonder.co.uk> writes
If you're talking about the first edition again, then maybe, just maybe,
since the definition of the language was necessarily somewhat fluid then.
But if you're talking about the edition with 'ANSI C' stamped in red on
the cover, then I am uncomprehending. I thought Kernighan and Ritchie had
always been *the* standard text on C.


No, I am talking about both editions. K&R is and has always been the
book for those who can already program and understand Unix environments.
AFAICR neither edition ever mentions lint and I do not know of a single
competent C programmer who does not use some tool to check inter
translation unit compatibility.

A whole bundle of errors perpetrated by the current generation of C
programmers just do not happen when lint or something similar is used.
--
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
Nov 14 '05 #23

P: n/a
In article <1Q**************@robinton.demon.co.uk>,
Francis Glassborow <fr*****@robinton.demon.co.uk> wrote:
In article <pa****************************@blueyonder.co.uk >, Alwyn
<al***@blueyonder.co.uk> writes
If you're talking about the first edition again, then maybe, just maybe,
since the definition of the language was necessarily somewhat fluid then.
But if you're talking about the edition with 'ANSI C' stamped in red on
the cover, then I am uncomprehending. I thought Kernighan and Ritchie had
always been *the* standard text on C.
No, I am talking about both editions. K&R is and has always been the
book for those who can already program and understand Unix environments.
AFAICR neither edition ever mentions lint and I do not know of a single
competent C programmer who does not use some tool to check inter
translation unit compatibility.
K&R does mention lint (at least in the 1st edition). In my copy looking
lint up in the index gives:
lint program verifier 3, 50, 68, 103, 141
Then page 3 gives:

For those situations where strong type checking is desirable, a separate
version of the compiler is used. This program is called lint, apparently
because it picks bits of fluff from one's program. lint does not generate
code, but instead applies a very strict check to as many aspects of a
program as can be verified at compile and load time. It detects type
mismatches, inconsistent argument usage, unused or apparently
uninitialized variables, potential portability difficulties, and the like.
Programs which pass unscathed through lint enjoy, with few exceptions,
freedom from type errors about as complete as do, for example Algol 68
programs. We will mention other lint capabilities as the occasion arises.
A whole bundle of errors perpetrated by the current generation of C
programmers just do not happen when lint or something similar is used.


I would agree that lint is a necessary part of programming in C. I wish
compilers would do more lint like checking.

Kevin.

Nov 14 '05 #24

P: n/a
On Mon, 29 Nov 2004 18:22:02 +0000, Francis Glassborow wrote:
In article <pa****************************@blueyonder.co.uk >, Alwyn
<al***@blueyonder.co.uk> writes
If you're talking about the first edition again, then maybe, just maybe,
since the definition of the language was necessarily somewhat fluid then.
But if you're talking about the edition with 'ANSI C' stamped in red on
the cover, then I am uncomprehending. I thought Kernighan and Ritchie had
always been *the* standard text on C.
No, I am talking about both editions. K&R is and has always been the
book for those who can already program and understand Unix environments.
AFAICR neither edition ever mentions lint and I do not know of a single
competent C programmer who does not use some tool to check inter
translation unit compatibility.


It has been pointed out to you more than once that K&R does refer to
'lint', at least in the first edition. Unfortunately, I cannot find my
own copy (2nd ed.) at the moment to check for myself, but if the remit was
to describe ANSI C, I don't see why they should be required to mention it.

Far be it from me to blow my own trumpet, but I can see no reason not to
be considered a competent C programmer, yet I have never had any dealings
with 'lint' and its ilk. As I understand it, it flags 'errors' like
writing 'printf("something");' instead of '(void)printf("something");',
which arguably makes for obfuscation.

'lint' was designed to compensate for the type-weakness of pre-standard C.
I've really no idea to what extent it has kept up with subsequent
developments in the language. The current crop of standard C compilers do
a decent job, in my opinion, though few attempt cross-translation-unit
type checking, owing, no doubt, to time constraints.
A whole bundle of errors perpetrated by the curret generation of C
programmers just do not happen when lint or something similar is used.


I entirely agree on the desirability of type-checking across compilation
units. My guess is that such a requirement was omitted from the C standard
mainly because it would have had a deleterious effect on compilation
times. It is really the compiler's job; no additional tool should be
required. Maybe in future, C compilers will do just that.
Alwyn

Nov 14 '05 #25

P: n/a
In article <4d********************@ntlworld.com>, kevin. bagust
<ke**********@ntlworld.com> writes
K&R does mention lint (at least in the 1st edition). In my copy looking
lint up in the index gives:
lint program verifier 3, 50, 68, 103, 141
Then page 3 gives:


Thanks for the correction.

--
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
Nov 14 '05 #26

P: n/a
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

[ ... ]
However be aware that it makes many implicit assumptions about the
programming environment.


Does it? I thought it only assumed a standard C compiler.


That's somewhat open to question -- in fact, the standard and the
language itself more or less make some implicit assumptions that the
environment is at least vaguely similar to UNIX.

Just for example, some environments don't provide anything much like
command-line arguments and/or environment variables. Admittedly, the
standard does allow for these to be absent, but if the original
environment had lacked them, the design would probably be different.

The book also pretty much assumes that they will be present and will
work (e.g. exercises that tell you to write programs that use
command-line arguments).

Of course, there's also chapter 8, which is devoted specificlaly to
the UNIX system interface. People totally unfamiliar with UNIX can
certainly glean something from it, but...
If you are already familiar with a Unix type development environment K&R
is excellent. If you are not, or are not using such an environment I am
less certain.


That is your privilege, but it would be nice if you could justify your
opinion just a little bit.


I can see where (for example) a person accustomed to MacOS <= 9.x
would probably find it somewhat difficult to understand some of what
they assume about how the user interacts with the OS.

In fairness, it should also be pointed out that to a large extent, the
world (at least of general-purpose computers) seems to have converged
on a model of OSes that's fairly similar to UNIX anyway.

Consider _The UNIX Programming Environment_ applies about equally well
to Windows with cygwin as to Linux, Solaris, HP-UX, etc.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Nov 14 '05 #27

P: n/a
On Mon, 29 Nov 2004 18:38:13 -0800, Jerry Coffin wrote:
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

[ ... ]
> However be aware that it makes many implicit assumptions about the
> programming environment.
Does it? I thought it only assumed a standard C compiler.


That's somewhat open to question -- in fact, the standard and the
language itself more or less make some implicit assumptions that the
environment is at least vaguely similar to UNIX.

Just for example, some environments don't provide anything much like
command-line arguments and/or environment variables. Admittedly, the
standard does allow for these to be absent, but if the original
environment had lacked them, the design would probably be different.

The book also pretty much assumes that they will be present and will
work (e.g. exercises that tell you to write programs that use
command-line arguments).


I take the point. I'd never before thought that command-line arguments
were 'a Unix thing'; I always thought of them as 'a C thing'.

<snip>
I can see where (for example) a person accustomed to MacOS <= 9.x would
probably find it somewhat difficult to understand some of what they
assume about how the user interacts with the OS.
Agreed, though many Macintosh programmers of that era would have used
Apple's MPW (Macintosh Programmer's Workbench), which was very Unix-like,
with make files and so forth.
In fairness, it should also be pointed out that to a large extent, the
world (at least of general-purpose computers) seems to have converged on
a model of OSes that's fairly similar to UNIX anyway.

Consider _The UNIX Programming Environment_ applies about equally well
to Windows with cygwin as to Linux, Solaris, HP-UX, etc.


There was also *Software Tools* by Kernighan and Plauger, which became a
handbook for a generation of programmers and helped popularise the 'Unix
approach' to software design and integration. The experience of preparing
the Pascal edition of this book led Kernighan to write his famous essay on
why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>
Alwyn

Nov 14 '05 #28

P: n/a
In <b2*************************@posting.google.com> jc*****@taeus.com (Jerry Coffin) writes:
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

[ ... ]
> However be aware that it makes many implicit assumptions about the
> programming environment.
Does it? I thought it only assumed a standard C compiler.


That's somewhat open to question -- in fact, the standard and the
language itself more or less make some implicit assumptions that the
environment is at least vaguely similar to UNIX.

Just for example, some environments don't provide anything much like
command-line arguments and/or environment variables. Admittedly, the
standard does allow for these to be absent, but if the original
environment had lacked them, the design would probably be different.

The book also pretty much assumes that they will be present and will
work (e.g. exercises that tell you to write programs that use
command-line arguments).


Implementations for environments with no support for this feature can
still meaningfully support it, by prompting the user to type the
command line arguments. Programs not needing them could disable the
feature. IIRC, this is how DECUS C for the PDP-11 worked.
Of course, there's also chapter 8, which is devoted specificlaly to
the UNIX system interface. People totally unfamiliar with UNIX can
certainly glean something from it, but...


They can learn *a lot* from it, because the few Unix primitives described
there are used to show the reader a bunch of non-trivial, real world
programming examples. I've read that chapter 4 years before getting
my first Unix account and I found it as useful and enlightening as the
rest of the book, even if my implementation didn't support any of those
primitives.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #29

P: n/a
In <1Q**************@robinton.demon.co.uk> Francis Glassborow <fr*****@robinton.demon.co.uk> writes:
No, I am talking about both editions. K&R is and has always been the
book for those who can already program and understand Unix environments.
As one of the many who have learned C from K&R without having the
slightest clue about Unix, my only comment to that is: bullshit!
AFAICR neither edition ever mentions lint and I do not know of a single
Your memory is faulty: several references to lint in K&R1. lint is
made superfluous by standard C, so K&R2 naturally ignores it (I suspect
there was no lint grokking standard C code in 1988, anyway).
competent C programmer who does not use some tool to check inter
translation unit compatibility.
A standard C compiler is enough for the job: competent C programmers know
how to use headers so that incompatibilities between translation units
are detected at compile time.
A whole bundle of errors perpetrated by the current generation of C
programmers just do not happen when lint or something similar is used.


lint is a very dangerous tool in the hands of the beginner, who is
naturally tempted to shut it up in the wrong way, especially when he
doesn't understand the nature of the complaint. It was the competent
programmer who could really benefit from lint, back in the K&R C days.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #30

P: n/a
Alwyn wrote:
On Mon, 29 Nov 2004 18:38:13 -0800, Jerry Coffin wrote:
Alwyn <al***@blueyonder.co.uk> wrote in message

[ ... ]

That's somewhat open to question -- in fact, the standard and the
language itself more or less make some implicit assumptions that the
environment is at least vaguely similar to UNIX.

Just for example, some environments don't provide anything much like
command-line arguments and/or environment variables. Admittedly, the
standard does allow for these to be absent, but if the original
environment had lacked them, the design would probably be different.

The book also pretty much assumes that they will be present and will
work (e.g. exercises that tell you to write programs that use
command-line arguments).


I take the point. I'd never before thought that command-line arguments
were 'a Unix thing'; I always thought of them as 'a C thing'.

<snip>

There was also *Software Tools* by Kernighan and Plauger, which became a
handbook for a generation of programmers and helped popularise the 'Unix
approach' to software design and integration. The experience of preparing
the Pascal edition of this book led Kernighan to write his famous essay on
why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


Software Tools was originally written in RatFor, and predates
Unix. Unfortunately Kernighan had various (understandable)
prebiases to his way of doing things, and thus did not appreciate
the advantages of Pascal. As far as command line parameters are
concerned, nothing ever prevents authors from including an initial
"getparameters" function call to supply what the OS does not. I
have always found it possible to make things quite user friendly,
although such may require some minor scripts to execute the
program.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #31

P: n/a
On Tue, 30 Nov 2004 18:22:57 +0000, CBFalconer wrote:

Software Tools was originally written in RatFor, and predates
Unix.
Pre-dates Unix? According to Amazon, the book dates from 1976, when Unix
could be considered to be five or six years old,
<http://www.amazon.com/exec/obidos/tg/detail/-/020103669X/002-6500922-1702446?v=glance>
<http://www.levenez.com/unix/history.html#01>
Unfortunately Kernighan had various (understandable)
prebiases to his way of doing things, and thus did not appreciate the
advantages of Pascal.
It's a rather personal essay, and it was written comparatively early in
the life of the language, but it is impossible to deny that he makes some
telling points. 'Extended' Pascals went on to become truly useful
languages on many architectures, but unfortunately, there was no commonly
accepted standard, and each vendor's implementation differed in
significant ways. Borland's Delphi (and now Kylix) is an important Rapid
Application Development platform even today, but it is very far removed
from the Pascal that Kernighan was writing today.
As far as command line parameters are concerned,
nothing ever prevents authors from including an initial "getparameters"
function call to supply what the OS does not. I have always found it
possible to make things quite user friendly, although such may require
some minor scripts to execute the program.


Yes, of course. Non-command-line-based development systems on the
Macintosh used to provide this.
Alwyn

Nov 14 '05 #32

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Unfortunately Kernighan had various (understandable) prebiases
to his way of doing things, and thus did not appreciate the
advantages of Pascal.


That's an understatement:
http://www.lysator.liu.se/c/bwk-on-pascal.html

Here's an excerpt:
People who use Pascal for serious programming fall into a fatal
trap.

Because the language is so impotent, it must be extended. But
each group extends Pascal in its own direction, to make it look
like whatever language they really want. Extensions for separate
compilation, Fortran-like COMMON, string data types, internal
static variables, initialization, octal numbers, bit operators,
etc., all add to the utility of the language for one group, but
destroy its portability to others.

I feel that it is a mistake to use Pascal for anything much
beyond its original target. In its pure form, Pascal is a toy
language, suitable for teaching but not for real programming.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Nov 14 '05 #33

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <1Q**************@robinton.demon.co.uk> Francis Glassborow
<fr*****@robinton.demon.co.uk> writes:

[...]
AFAICR neither edition ever mentions lint and I do not know of a single


Your memory is faulty: several references to lint in K&R1. lint is
made superfluous by standard C, so K&R2 naturally ignores it (I suspect
there was no lint grokking standard C code in 1988, anyway).


The lint that existed at the time is probably obsolete today, but
there are a number of lint-like tools today that can perform useful
checks that compilers may not perform.

Personally, I don't particularly like the idea of making lint a
separate program rather than a set of options to the compiler. After
all, both the compiler and lint have to do much of the same work. And
hacking your code until you get no warnings at all from lint may be
misguided. But current lint-like tools can be useful if you know what
you're doing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #34

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <1Q**************@robinton.demon.co.uk> Francis Glassborow
<fr*****@robinton.demon.co.uk> writes:

[...]
AFAICR neither edition ever mentions lint and I do not know of a single


Your memory is faulty: several references to lint in K&R1. lint is
made superfluous by standard C, so K&R2 naturally ignores it (I suspect
there was no lint grokking standard C code in 1988, anyway).


The lint that existed at the time is probably obsolete today, but
there are a number of lint-like tools today that can perform useful
checks that compilers may not perform.

Personally, I don't particularly like the idea of making lint a
separate program rather than a set of options to the compiler. After
all, both the compiler and lint have to do much of the same work. And
hacking your code until you get no warnings at all from lint may be
misguided. But current lint-like tools can be useful if you know what
you're doing.


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

The worst feature of lint is that you have to start desabling default
checks in order to turn it into a useful tool: it simply generates too
much noise by default. And I hate the idea of inserting comments for
lint's consumption in my code.

As I already said, the introduction of function prototypes allowed the
compiler, with help from the programmer, to perform the part of lint's
job that was really a *must* before standard C: inter-translation unit
consisitency checks.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #35

P: n/a
CBFalconer <cb********@yahoo.com> wrote:
Alwyn wrote:
There was also *Software Tools* by Kernighan and Plauger, which became a
handbook for a generation of programmers and helped popularise the 'Unix
approach' to software design and integration. The experience of preparing
the Pascal edition of this book led Kernighan to write his famous essay on
why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


Software Tools was originally written in RatFor, and predates
Unix. Unfortunately Kernighan had various (understandable)
prebiases to his way of doing things, and thus did not appreciate
the advantages of Pascal.


That would be the advantage of having to put all your typedefs together,
all your variables together, all your constants together, etcetera? A
practice, btw, which is similar to putting all verbs of an English
sentence first, then all adverbs, then all adjectives, etcetera. Or
rather, is putting similar first then then English A an which all all
all practice verbs sentence adverbs adjectives to of btw etcetera,,,,,.
Or perhaps the advantage of having no file handling to speak of, and
what's worse, no way to handle input errors gracefully.

AAMOF, I probably agree with everything Kernighan says about Pascal in
that document, and I learned Pascal before C. Pascal is a great teaching
language, for the same reason that it is a lousy programming language:
it's severely and often unreasonably B&D.

Richard
Nov 14 '05 #36

P: n/a
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

There was also *Software Tools* by Kernighan and Plauger, which became a
handbook for a generation of programmers and helped popularise the 'Unix
approach' to software design and integration. The experience of preparing
the Pascal edition of this book led Kernighan to write his famous essay on
why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


Interesting reading! As with all writings produced by the Bell Labs'
guys, the essay is quite thorough and yet succinct.

Although Kernighan promises otherwise, he does succumb into comparing
Pascal with C. And some of the holes that he shoots are dubious ("no
casts in Pascal" (2.6), no "break statement"(3), no "macro
preprocessor" (5) are presented as cases to make his point!). That
said, there is rigour to the article - as you'd expect from Kernighan.

- Anand
Nov 14 '05 #37

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

[...]
Personally, I don't particularly like the idea of making lint a
separate program rather than a set of options to the compiler. After
all, both the compiler and lint have to do much of the same work. And
hacking your code until you get no warnings at all from lint may be
misguided. But current lint-like tools can be useful if you know what
you're doing.


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

The worst feature of lint is that you have to start desabling default
checks in order to turn it into a useful tool: it simply generates too
much noise by default. And I hate the idea of inserting comments for
lint's consumption in my code.

As I already said, the introduction of function prototypes allowed the
compiler, with help from the programmer, to perform the part of lint's
job that was really a *must* before standard C: inter-translation unit
consisitency checks.


Anyone who's interested in exploring this might take a look at Splint,
formerly LCLint, available at <http://www.splint.org/>. (This is not
an advertisement, just a mention.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #38

P: n/a
Richard Bos wrote:
CBFalconer <cb********@yahoo.com> wrote:
Alwyn wrote:

There was also *Software Tools* by Kernighan and Plauger, which
became a handbook for a generation of programmers and helped
popularise the 'Unix approach' to software design and integration.
The experience of preparing the Pascal edition of this book led
Kernighan to write his famous essay on why Pascal was not his
favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


Software Tools was originally written in RatFor, and predates
Unix. Unfortunately Kernighan had various (understandable)
prebiases to his way of doing things, and thus did not appreciate
the advantages of Pascal.


That would be the advantage of having to put all your typedefs
together, all your variables together, all your constants together,
etcetera? A practice, btw, which is similar to putting all verbs of
an English sentence first, then all adverbs, then all adjectives,
etcetera. Or rather, is putting similar first then then English A
an which all all all practice verbs sentence adverbs adjectives to
of btw etcetera,,,,,. Or perhaps the advantage of having no file
handling to speak of, and what's worse, no way to handle input
errors gracefully.


No, that would be the advantage of having closely typed variables
and subranges, so that indexing one array with something out of
range is caught immediately, usually at compile time. It would be
having the advantage of a file system with carefully specified
semantics and automatic look ahead, so that all interactive input
can be guarded exactly as needed. It would be the advantage of
controlled pointers, so that no wild pointer access can occur (with
some relatively rare exceptions). It would be the advantage of
nested subroutines, so that the code can be truly structured. It
would be the advantage of having confidence in the accuracy of the
software.

Yes, it is possible to write accurate and correct software in C.
However the probability of this from the average programmer is
extremely low. All you have to do is look around c.l.c for the
silly gaffes committed every day.

As I pointed out before, it takes proper familiarity with Pascal to
appreciate its advantages. I did not attempt to start any wars and
I fail to see why you want to. Use the languages as and where
appropriate.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #39

P: n/a
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

[ ... ]
In fairness, it should also be pointed out that to a large extent, the
world (at least of general-purpose computers) seems to have converged on
a model of OSes that's fairly similar to UNIX anyway.

Consider _The UNIX Programming Environment_ applies about equally well
to Windows with cygwin as to Linux, Solaris, HP-UX, etc.
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.

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.
which became a
handbook for a generation of programmers and helped popularise the 'Unix
approach' to software design and integration. The experience of preparing
the Pascal edition of this book led Kernighan to write his famous essay on
why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


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.

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.

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.

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

--
Later,
Jerry.

The universe is a figment of its own imagination.
Nov 14 '05 #40

P: n/a
On Thu, 02 Dec 2004 08:53:25 -0800, Jerry Coffin wrote:
Alwyn <al***@blueyonder.co.uk> wrote in message news:<pa****************************@blueyonder.co .uk>...

[ ... ]
> In fairness, it should also be pointed out that to a large extent, the
> world (at least of general-purpose computers) seems to have converged on
> a model of OSes that's fairly similar to UNIX anyway.
>
> Consider _The UNIX Programming Environment_ applies about equally well
> to Windows with cygwin as to Linux, Solaris, HP-UX, etc.
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.
which became a
handbook for a generation of programmers and helped popularise the
'Unix approach' to software design and integration. The experience of
preparing the Pascal edition of this book led Kernighan to write his
famous essay on why Pascal was not his favourite programming language.
<http://www.lysator.liu.se/c/bwk-on-pascal.html>


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

Nov 14 '05 #41

P: n/a
"Herbert Rosenau" <os****@pc-rosenau.de> wrote in message news:<cl****************@plethora.net>...
On Sun, 21 Nov 2004 03:50:27 UTC, "Jhon smith"
<jh**********@hotmail.com> wrote:
C The complete reference---Herbert schildt first edition,1987


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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #42

P: n/a
Da*****@cern.ch (Dan Pop) writes:
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. :)
Nov 14 '05 #43

P: n/a
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
Da*****@cern.ch (Dan Pop) writes:
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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #44

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
Da*****@cern.ch (Dan Pop) writes:
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.


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.
Nov 14 '05 #45

P: n/a
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:
>Da*****@cern.ch (Dan Pop) writes:
>
>> 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.
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.


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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #46

P: n/a
In article <cl****************@plethora.net>, JeffS <ja*@rfgen.com>
writes
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.
--
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
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #47

P: n/a
ja*@rfgen.com (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.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net
Nov 14 '05 #48

P: n/a
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:

>Da*****@cern.ch (Dan Pop) writes:
>
>> 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.

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.


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.

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 }

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.

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.

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?


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.
Nov 14 '05 #49

P: n/a
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:

> In <kf*************@alumnus.caltech.edu> Tim Rentsch <tx*@alumnus.caltech.edu> writes:
>
> >Da*****@cern.ch (Dan Pop) writes:
> >
> >> 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.
>
> 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. :)
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.)"

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

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

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.
[snip]
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). 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.

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.

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.

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.

"-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
Nov 14 '05 #50

90 Replies

This discussion thread is closed

Replies have been disabled for this discussion.