| Type | Page | Error | Correction | Reported By |
|---|---|---|---|---|
| Typographical | 344 | 'disk-spaced' | 'disk-based' - I think I must have been dictating this out loud to myself, and not listening very carefully! | |
| Technical | 356 | Oooh boy. This one's a corker. The whole technique of storing an 2-D
array of T by having one contiguous block of memory
containing a bunch of T* at the front of the block,
each pointing into the block, is flawed. It may work on
some systems some of the time, as does a lot of
code which relies on undefined behaviour! The problem here is that
objects of type T are not guaranteed by the ISO
C Standard to require the same alignment characteristics as objects
of type T*, yet this technique depends upon such a
guarantee. |
Insert, after the paragraph beginning "You may care...",
the following paragraph: "Apart from the problems inherent in
writing and maintaining this code, we should also bear in mind that
implementations are not required to give a type T the
same alignment characteristics as a type T*. This
technique, therefore, exhibits undefined behaviour, and should
not be used." Also, in the paragraph beginning "The third method..." change "easier to resize." to "easier to resize, and is legal too - always a bonus!" Update 3 Nov 2000 - Chris Mears complains that this error starts way back on page 353, and continues all the way through to page 356. Pay no attention; he's just being picky. :-) |
|
| Technical | 365, 366, 367 | All the error macros (e.g. ERR_ROWS_NOT_ADDED) use a reserved namespace, i.e. E followed by an upper case letter. |
Wherever you see ERR_ starting a token, change the start of the token to READ_FILE_ERR_, leaving the rest of the token intact - e.g. ERR_ROWS_NOT_ADDED should read READ_FILE_ERR_ROWS_NOT_ADDED. |
|
| Technical | 369 | The paragraph just before the section "Arrays of Pointers" is a little misleading. Here's a much better wording, with the additions picked out in bold type: | If this were a big problem, we'd find a solution. But it's not a big problem because multi-dimensional arrays with more than, say, four dimensions are actually rarely needed (in fact, they are used more often than they should be). If we find ourselves using such multi-dimensional arrays as a matter of habit, we really ought to be questioning our design. | |
| Technical | 373 | "declare all the functions as int()" |
Should be "declare all the pointers to function as int(*)()" |
|
| Typographical | 385 | struct | Should be struct |
|
| Technical | 397 | In the 'Insertion at End' paragraph,
DLGetNext() is clearly wrong. |
Should be DLGetLast() |
Bob Wightman |
| Technical | 437 | The heap reallocation in HeapInsert()
is flawed. |
Define a spare pointer for the reallocation. | Bob Wightman |