Learning C with Older books ?.

[Dan Pop]

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

 

[Alwyn]

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

 

[Francis Glassborow]

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.

 

[kevin.bagust]

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.

 

[Alwyn]

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

 

[Francis Glassborow]

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.

 

[Jerry Coffin]

[ ... ]

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

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.

 

[Alwyn]

[ ... ]

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

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

 

[Dan Pop]

[ ... ]

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]

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

 

[CBFalconer]

[ ... ]

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.

 

[Alwyn]

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>

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

 

[Ben Pfaff]

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.

 

[Keith Thompson]

In <[email protected]> Francis Glassborow


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.

 

[Dan Pop]

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

 

[Richard Bos]

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

 

[Anand Hariharan]

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

 

[Keith Thompson]

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

 

[CBFalconer]

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.

 

[Jerry Coffin]

[ ... ]

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.