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

K&R reference.

P: n/a
I know that K&R I exists. Wonderful reference.
I know K&R II exists, even bought a couple. ANSI C (C89) is a wonderful
thing. Works fine.

Now that we have had C99 (or whatever it is called these days) is there
any hope that something the equivalent of K&R III might be written??

I suspect that there IS an audience for it. You know: If they write it
we will read/buy it!!

I personally found the style of K&R VERY helpful and the explanations
even better. The "manual" was only about 10 mm or so in thickness.

Personally I found the C++ manual (Look I picked it up when Bjarne gave
a lecture locally) a little wordy, and the examples mostly incomplete.
There were many examples that ended with:

// ...

Which got a bit annoying. This is my personal opinion!!

Any authors in the audience??
--
Tom Watson Generic short signature
ts*@johana.com I'm at home now.

Nov 14 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
In <lU*******************@newssvr29.news.prodigy.co m> Tom Watson <ts*@johana.com> writes:
I know that K&R I exists. Wonderful reference.
I know K&R II exists, even bought a couple. ANSI C (C89) is a wonderful
thing. Works fine.

Now that we have had C99 (or whatever it is called these days) is there
any hope that something the equivalent of K&R III might be written??


Not by K&R, anyway. Apparently, C99 is too baroque for their taste.

OTOH, given the "wealth" of conforming C99 implementations, the
need for such a book is less obvious now than it was 5 years ago...

Apparently, there is one tutorial book covering C99 (but I doubt the
author had access to any conforming implementation to test his examples)
and the 5th edition of H&S covers C99, too.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #2

P: n/a
Dan Pop <Da*****@cern.ch> wrote:

Not by K&R, anyway. Apparently, C99 is too baroque for their taste.


That's not what DMR said. He said that they weren't planning an update
because the changes to the core language were small and that's what the
white book is really about. The big changes were in the library, which
the white book doesn't get into except in passing.

-Larry Jones

I've never seen a sled catch fire before. -- Hobbes
Nov 14 '05 #3

P: n/a
In <nd************@jones.homeip.net> la************@ugsplm.com writes:
Dan Pop <Da*****@cern.ch> wrote:

Not by K&R, anyway. Apparently, C99 is too baroque for their taste.


That's not what DMR said. He said that they weren't planning an update
because the changes to the core language were small and that's what the
white book is really about. The big changes were in the library, which
the white book doesn't get into except in passing.


Read Appendix B carefully. It might be small, but it's a fairly
accurate reference description of the C89 standard library (with
minimal omissions). Imagine "upgrading" it to C99 and you'll easily
figure out the lack of interest of the authors towards a C99 version
of K&R.

You know as well as myself that the changes to the core language are not
small, they are just not as big as the additions to the standard library.
I have removed the library references from the following quote from C99's
foreword:
Major changes from the previous edition include:

- restricted character set support via digraphs and <iso646.h>
(originally specified in AMD1)

- more precise aliasing rules via effective type

- restricted pointers

- variable-length arrays

- flexible array members

- static and type qualifiers in parameter array declarators

- complex (and imaginary)

- the long long int type

- increased minimum translation limits

- additional floating-point characteristics in <float.h>

- remove implicit int

- reliable integer division

- universal character names (\u and \U)

- extended identifiers

- compound literals

- designated initializers

- // comments

- remove implicit function declaration

- preprocessor arithmetic done in intmax_t/uintmax_t

- mixed declarations and code

- new block scopes for selection and iteration statements

- integer constant type rules

- integer promotion rules

- macros with a variable number of arguments

- trailing comma allowed in enum declaration

- inline functions

- idempotent type qualifiers

- empty macro arguments

- new struct type compatibility rules (tag compatibility)

- additional predefined macro names

- _Pragma preprocessing operator

- standard pragmas

- __func__ predefined identifier

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #4

P: n/a
Da*****@cern.ch (Dan Pop) wrote:

I have removed the library references from the following quote from C99's
foreword:

Major changes from the previous edition include:

- reliable integer division


What does this mean exactly?
I worked with a compiler once where the expression (ULONG_MAX / 10)
evaluated to garbage, and similarly for any numbers more than
about 2/3 of ULONG_MAX, IIRC. I always assumed this was a bug
(a reasonable assumption, given that it also did things like failing
to promote the arguments of calls to variadic functions).
Nov 14 '05 #5

P: n/a
ol*****@inspire.net.nz (Old Wolf) writes:
Da*****@cern.ch (Dan Pop) wrote:

I have removed the library references from the following quote from C99's
foreword:

Major changes from the previous edition include:

- reliable integer division


What does this mean exactly?


C89 (draft):

----------------------------------------------------------------------
The result of the / operator is the quotient from the division of
the first operand by the second; the result of the % operator is the
remainder. In both operations, if the value of the second operand is
zero, the behavior is undefined.

When integers are divided and the division is inexact, if both
operands are positive the result of the / operator is the largest
integer less than the algebraic quotient and the result of the %
operator is positive. If either operand is negative, whether the
result of the / operator is the largest integer less than the
algebraic quotient or the smallest integer greater than the algebraic
quotient is implementation-defined, as is the sign of the result of
the % operator. If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a .
----------------------------------------------------------------------

C99:

----------------------------------------------------------------------
5 The result of the / operator is the quotient from the division
of the first operand by the second; the result of the %
operator is the remainder. In both operations, if the value
of the second operand is zero, the behavior is undefined.

6 When integers are divided, the result of the / operator is the
algebraic quotient with any fractional part discarded.87) If
the quotient a/b is representable, the expression (a/b)*b +
a%b shall equal a.

87) This is often called ``truncation toward zero''.
----------------------------------------------------------------------
--
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 #6

P: n/a
Old Wolf wrote:

Da*****@cern.ch (Dan Pop) wrote:

I have removed the library references from the following quote from C99's
foreword:

Major changes from the previous edition include:

- reliable integer division
What does this mean exactly?


It refers to divisions involving negative integers. Original
ANSI C allows the quotient of -5 / 3 to be either -1 or -2, rounding
upward or downward. The remainder obtained by the modulus operator
had to be consistent with the quotient: -2 or +1 in these examples,
so the identity (-5 / 3) * 3 + (-5 % 3) == -5 was always satisfied.
The div() and ldiv() functions were provided if you absolutely needed
round-toward-zero behavior, but they are less convenient to use in
expressions than / and %.

C99 requires round-toward-zero, period. The C99 Rationale says
the change was motivated by a desire to be more like Fortran. I
kid you not.
I worked with a compiler once where the expression (ULONG_MAX / 10)
evaluated to garbage, and similarly for any numbers more than
about 2/3 of ULONG_MAX, IIRC. I always assumed this was a bug
(a reasonable assumption, given that it also did things like failing
to promote the arguments of calls to variadic functions).


Failing to compute ULONG_MAX / 10 is certainly a bug, and your
other bad experiences with the compiler are suggestive. However,
there's an all-too-common way for a program to get this wrong.
Can you spot the bug in

printf ("ULONG_MAX / 10 = %d\n", ULONG_MAX / 10);

? (Hint: gcc can spot it.) If your evidence for garbage rests
on something like this, it'll be thrown out of Court.

--
Er*********@sun.com
Nov 14 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.