ANN: Long-overdue CU bug-fix

[Richard Heathfield]

I got an email today from a CU reader who wanted to know what had
happened to Chapter 15's sparse.c and sparse.h - neither of which
appear on the CD. He was ever so polite about it, mind you - but I
still felt really guilty because of course this should never have
happened.

The sparse.c omission was easy to explain - that was the original name
of a file which was later split into many. But the sparse.h header was
in fact completely missing. The author of the relevant chapter did once
send me the header (about two or three years after publication!) but
this was at a time when my work schedule was more insane than usual and
I lost track of it completely, together with his email address, when a
disk crashed; a disk that should have been backed up and wasn't.

I have spent today reconstructing the header from information provided
in the text and from hints in the source files, and then getting the
test-driver to work. This involved a considerable amount of hacking,
during the course of which I must have removed something like 200
unnecessary casts! (They were in my way, making the code harder to
read, so they had to go. I think there probably are still plenty left,
though, in the code I /didn't/ touch...)

The revised code is now freely available on my Web site:

http://www.cpax.org.uk/prg/portable/c/unleashed/code/ch15/CUnleashedChapter15Code.zip

It's about 20KB, and I have about 480kbps upload (in theory) - so if you
time it right, it shouldn't take more than about twenty minutes to
grab. (If you're astoundingly lucky, of course, it'll only take half a
second or so.)

 

[jacob navia]

Richard Heathfield wrote:

[snip]

Are the other bugs in C Unleashed fixed?

Specifically in Chapter 11, page 353 you assume
sizeof pointer is equal to sizeof int...

Here is the buggy code:
It will work when sizeof pointer is equal to sizeof int
(windows or linux 32 bit versions) but will crash when
sizeof int != sizeof pointer (windows 64 bits.

Exercise:

Where does Heathfield go wrong?

#include <stdio.h>
#include <stdlib.h>
typedef int T;
T **Allocate(size_t m,size_t n)
{
T **a;
T *p;
size_t Row;

a = malloc(m*n*sizeof **a + m * sizeof *a);
if (a) {
for (Row=0,p=(T *)a + m; Row < m; Row++,p+=n) {
a[Row]=p;
}
}
return a;
}

int main(void)
{
T **array;
int i;
int j;
int total=0;
int Row=4;
int col=7;

array = Allocate(Row,col);
if (array != NULL) {
for (i=0; i<Row;i++)
for (j=0; j<col; j++)
array[j] = i+j;
for (i=0; i<Row;i++)
for(j=0;j<col;j++)
total+=array[j];

printf("Total is %d\n",total);
free(array);
}
return 0;
}

 

[Philip Potter]

Richard Heathfield wrote:

[snip]

Are the other bugs in C Unleashed fixed?

Specifically in Chapter 11, page 353 you assume
sizeof pointer is equal to sizeof int...

Here is the buggy code:
It will work when sizeof pointer is equal to sizeof int
(windows or linux 32 bit versions) but will crash when
sizeof int != sizeof pointer (windows 64 bits.

Exercise:

Where does Heathfield go wrong?

One of your most-used arguments against your critics is that their arguments are
not backed up by substance. Here you are not bothering to point out the bug, but
are instead dressing it as an "exercise". This removes the substance from your
argument.

Phil

 

[Richard Heathfield]

Philip Potter said:

Richard Heathfield wrote:

[snip]

Are the other bugs in C Unleashed fixed?

Specifically in Chapter 11, page 353 you assume
sizeof pointer is equal to sizeof int...

Here is the buggy code:
It will work when sizeof pointer is equal to sizeof int
(windows or linux 32 bit versions) but will crash when
sizeof int != sizeof pointer (windows 64 bits.

Exercise:

Where does Heathfield go wrong?

One of your most-used arguments against your critics is that their
arguments are not backed up by substance. Here you are not bothering
to point out the bug, but are instead dressing it as an "exercise".
This removes the substance from your argument.

I don't think that's such a big deal, actually; he does, after all, give
a pretty reasonable summary of the bug. But Mr Navia is referring to an
error which was reported, acknowledged, and entered into the book's
errata list ***seven years*** ago.

Perhaps, for an encore, Mr Navia would like to attack Messrs Kernighan
and Ritchie for the errors to be found in "The C Programming Language",
2nd edition. He can find ammunition here:
http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html

In a rare fit of energy, I have just spent a little time copying the "C
Unleashed" errata to my current Web site, and I've taken the
opportunity to add one or two extra notes. Suspicious minds should note
that the int/int * erratum is present on the original errata page cited
in the book itself, and that page is hosted on a site to which I have
not had write access for several years, as I have had cause to mention
once or twice before in this group.

The new errata site is here:

http://www.cpax.org.uk/prg/portable/c/unleashed/errata/index.php

Plenty there for Mr Navia to criticise. In the meantime, perhaps the
rest of us can move on to more interesting subjects, such as C
programming.

(I am, of course, always glad to hear of CU bugs that are /not/ present
on the errata list. Well, not glad, but you know what I mean.)

 

[jacob navia]

I don't think that's such a big deal, actually; he does, after all, give
a pretty reasonable summary of the bug. But Mr Navia is referring to an
error which was reported, acknowledged, and entered into the book's
errata list ***seven years*** ago.

Excuse me I wasn't aware of that.

 

[Joachim Schmitz]

In a rare fit of energy, I have just spent a little time copying the "C
Unleashed" errata to my current Web site, and I've taken the
opportunity to add one or two extra notes. Suspicious minds should note
that the int/int * erratum is present on the original errata page cited
in the book itself, and that page is hosted on a site to which I have
not had write access for several years, as I have had cause to mention
once or twice before in this group.

The new errata site is here:

http://www.cpax.org.uk/prg/portable/c/unleashed/errata/index.php

Plenty there for Mr Navia to criticise. In the meantime, perhaps the
rest of us can move on to more interesting subjects, such as C
programming.

(I am, of course, always glad to hear of CU bugs that are /not/ present
on the errata list. Well, not glad, but you know what I mean.)

Found a problem with the errata: on
http://www.cpax.org.uk/prg/portable/c/unleashed/errata/ech13.php there's an
orphaned hyperlink to
http://www.cpax.org.uk/prg/portable/c/unleashed/errata/896213nw.zip

And on the main page you mention "the old site" without hyperlinking to it

Interesting reading BTW, made me curious for the book itself...

Bye, Jojo

 

[Richard Heathfield]

Joachim Schmitz said:

Found a problem with the errata: on
http://www.cpax.org.uk/prg/portable/c/unleashed/errata/ech13.php
there's an orphaned hyperlink to
http://www.cpax.org.uk/prg/portable/c/unleashed/errata/896213nw.zip

Whoops! Fixed. Thanks.

And on the main page you mention "the old site" without hyperlinking
to it

That is deliberate. The old site should be considered dead, really. I'm
astounded that it has remained "up" all these years, since nobody is
paying for it! It is outside my control, and its plug could be pulled
at any time, so I don't want to draw any more attention to it than is
absolutely necessary.

Interesting reading BTW, made me curious for the book itself...

It had not occurred to me that a bug list could be a selling point.

Unfortunately, the book went out of print a while back; so, if you want
to read it, you'll have to content yourself with a second-hand copy.

 

[CBFalconer]

Joachim Schmitz said:

.... snip about C Unleashed ...

It had not occurred to me that a bug list could be a selling point.

Unfortunately, the book went out of print a while back; so, if you want
to read it, you'll have to content yourself with a second-hand copy.

Ahh - so my copy is attaining antique status and elevated value.
Just like me. I think I have peaked, but hopefully CU hasn't yet.

 

[Joachim Schmitz]

Unfortunately, the book went out of print a while back; so, if you want
to read it, you'll have to content yourself with a second-hand copy.

Amazon still liste a few dealers (3, to be exact) that sell it as being new.

Bye, Jojo

 

[Joachim Schmitz]

Joachim Schmitz said:

That is deliberate. The old site should be considered dead, really. I'm
astounded that it has remained "up" all these years, since nobody is
paying for it! It is outside my control, and its plug could be pulled
at any time, so I don't want to draw any more attention to it than is
absolutely necessary.

I found it anyway

Bye, Jojo

 

[Malcolm McLean]

Richard Heathfield wrote:

[snip]

Are the other bugs in C Unleashed fixed?

Specifically in Chapter 11, page 353 you assume
sizeof pointer is equal to sizeof int...

Here is the buggy code:
It will work when sizeof pointer is equal to sizeof int
(windows or linux 32 bit versions) but will crash when
sizeof int != sizeof pointer (windows 64 bits.

Exercise:

Where does Heathfield go wrong?

He's using the same array for a list of T*s and a following list of Ts.
It's very tempting to do that, but the standard won't allow it. There is mo
guarantee that T*s and Ts have compatible alignment, for one thing. The bug
you mention, however, appears to be in the calcualtion of the T list offset.

However it is quite diffiuclt to keep bugs out of books, for several
reasons. One is that example or teaching code tends not be heavily used in
real applications. Of course you test it, but that's it. It doesn't face the
constant demands of an industrial subroutine.

It irritates me when people point out bugs in Basic Algorithms and then
insinuate that the book is no good. The bug report itself doesn't irritate,
of course, just the implication that there is something seriously wrong with
the book. I see no reason why Richard Heathfield's books should be any
different.

 

[Mark McIntyre]

Richard Heathfield wrote:

(a post about fixing a problem with the CU CD).

Are the other bugs in C Unleashed fixed?

This is a valid question. Unfortunately you totally destroy your
credibility by turning it into yet another gratuitous attack on
Richard.

Where does Heathfield go wrong?

By bothering with fools like you.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Malcolm McLean said:

However it is quite diffiuclt to keep bugs out of books, for several
reasons. One is that example or teaching code tends not be heavily
used in real applications. Of course you test it, but that's it. It
doesn't face the constant demands of an industrial subroutine.

It irritates me when people point out bugs in Basic Algorithms and
then insinuate that the book is no good.

Malcolm - there will never be another print of "C Unleashed", with the
bugs and typos corrected. So I'm stuck with my bugs - I can't do
anything about them.

Your book, on the other hand, is electronic. You can change it whenever
you like. I urge you to change it.

You are *not* stuck with your bugs for all time. I urge you to fix them.

You, unlike me, now have the chance to make your book perfect. I urge
you to take it.

 

[=?iso-8859-1?q?Asbj=F8rn_S=E6b=F8?=]

[...]

Unfortunately, the book [C Unleashed] went out of print a while
back; so, if you want to read it, you'll have to content yourself
with a second-hand copy.

Actually, I found (and bought) a new copy this winter, from a webshop
in the US I found through Amazon.

Asbjørn

 

[Francine.Neary]

Malcolm McLean said:




Malcolm - there will never be another print of "CUnleashed", with the
bugs and typos corrected. So I'm stuck with my bugs - I can't do
anything about them.

If there's no prospect of a reprinting, why not negotiate with the
publisher for the right to make a PDF available on the web?

 

[Richard Heathfield]

(e-mail address removed) said:

Francine - in my original article, there was a space between 'C' and 'U'
which your news software appears to have elided. How much do I care?
Not very much, except insofar as we all care about not being misquoted.
But *you* might care enough to inspect your news software for bugs.

If there's no prospect of a reprinting, why not negotiate with the
publisher for the right to make a PDF available on the web?

I tried to contact the publisher in January this year on a related
matter, but was ignored with impressive impassivity. My contacts within
the publishing company, which are almost a decade old, appear to have
rusted.

 

[Joachim Schmitz]

(e-mail address removed) said:


I tried to contact the publisher in January this year on a related
matter, but was ignored with impressive impassivity. My contacts within
the publishing company, which are almost a decade old, appear to have
rusted.

Shouldn't that mean that you can safely assume 'in good faith' that they
lost interest and don't care about you publishing it on the web?

Bye, Jojo

 

[Richard Heathfield]

Joachim Schmitz said:

Shouldn't that mean that you can safely assume 'in good faith' that
they lost interest and don't care about you publishing it on the web?

No, it doesn't mean that, alas.

 

[Antoninus Twink]

Then if you can't publicly put it on a web-site, would you be prepared
to email the PDF privately by request? It's surprisingly hard to find a
PDF in the usual places...

Joachim Schmitz said:


No, it doesn't mean that, alas.

--

 

[Keith Thompson]

Then if you can't publicly put it on a web-site, would you be prepared
to email the PDF privately by request? It's surprisingly hard to find a
PDF in the usual places...

Top-posting corrected. Please read:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

Presumably the publisher owns the copyright on the book. You're
asking Richard to violate that copyright (and the "usual places"
probably specialize in copyright violation).

I've seen cheap used copies for sale on www.barnesandnoble.com.
(There are only two, and now that I've posted this they'll probably go
quickly.)