Re: Learning C with Older books ?.

From: Alwyn (alwyn_at_blueyonder.co.uk)
Date: 11/29/04 

Date: Mon, 29 Nov 2004 19:56:10 GMT

On Mon, 29 Nov 2004 18:22:02 +0000, Francis Glassborow wrote:

> In article <pan.2004.11.29.15.49.23.676626@blueyonder.co.uk>, Alwyn
> <alwyn@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

Relevant Pages

  • Re: Learning C with Older books ?.
    ... >>since the definition of the language was necessarily somewhat fluid then. ... 'lint', at least in the first edition. ... be considered a competent C programmer, yet I have never had any dealings ... C compilers will do just that. ...
    (comp.lang.c)
  • Re: Global Variables : Where are they stored ?
    ... Most of the fancy language features are nothing to do with portability, it is actually the simple language facilities such as sizeof, limits.h and knowing what is undefined that allow you to keep all your compilers happy. ... what percentage of programmer are really ... There are exactly two groups of people who should really know what the standard guarantees... ...
    (comp.lang.c)
  • Re: Java is slow!
    ... but compilers do not escape the rule. ... Languages like C++ or even C# can beat Java in performance because ... they allow the programmer more control. ... programmer complicates the language and using it takes time and effort. ...
    (comp.lang.java.advocacy)
  • Re: These are identical, right? char const* and const char*
    ... > One thing I actually like about teaching Java is that when anyone asks why ... from such ambiguity in the language to the inadequacy of the programmer. ... compilers to be able to compile to a specified version of the standard, ...
    (comp.lang.cpp)
  • Re: whats wrong with a pic ?
    ... They are just fine for an assembly programmer who is used to ... notwithstanding the alleged C compilers for them. ... elementary requirements of the C language, ... you have no standards on which to rely. ...
    (comp.arch.embedded)