Efficency and the standard library

[Seebs]

I do not recall coining such a term. I have seen it used, certainly, but I
hardly think I invented it.

This kind of thing contributes to your difficulty persuading people that
you are in any way something other than a kook.


-s

 

[spinoza1111]

[snips]

Hmm?  Truth - even trivial truth - is now somehow a bad thing?

Say what?

"Dogs are members of the family Felidae".  It's clear, it's
understandable, it's flat-out wrong.

Not as a speech act. Grownups, engaged in civil discourse, endeavor to
discover why the above statement is being made. Children, on the other
hand, are used to being lied to.
I've already explained that: clarity is understandability (as you
concede) but "understanding" is "knowledge", and knowledge is
justified belief in things that are true. Therefore, because Schildt
is clear, he is understandable, and if he is understandable, he giveth
understanding, and the understanding that he giveth can be naught else
than knowledge, the justified belief in aught that is true and naught
that is false. Let this be a lesson unto ye.

In fact, only a clumsy writer would have said up front, as Seebie-
Weebie said, that Herb is "clear". Shot himself in the foot he did. I
would have written "Herb's texts have only an apparent clarity" in
Churchillian tones, going on to say,

"This clarity is marred by clarity's enemy, which is error. Members of
this House are reminded that we may not say with sense, that the
leader of the opposition party is 'clear' when in one speech, he makes
such egregious errors on the situation of our forces in South Africa,
therefore I demur from my respected fellow Party member's opinion,
that the Prime Minister was 'clear' but 'wrong'."

"In fact, his Grace was unclear to the charitable and enlightened
section of opinion, which in a Liberal spirit reaches across the
sword's length of this House and endeavors, so far as it is able, to
find truth in error, and sound policy in misadventure. Try as we
might, like the Hindoo fakir endeavoring to find sound advice in his
Sans-crit text amidst lurid folly, Asiatic extravagance, and wearisome
prolixity, we cannot put a sensible construction on this Government's
intentions and policy, and must therefore call that policy a fog, a
fug, a mist, and most unclear."

 

[spinoza1111]

[snips]

English public school rules apply to this fight, Bart: cf. Flashman's
savaging of Tom Brown in Tom Brown's Schooldays. Which is why it's so
much fun to win, as I am winning, despite Seebie's Flashman-like
behavior. He can't get a simple strlen replace right, yet dares to
attack my much more sophisticated and challenging solution and Schildt.

He had a bug.  Since that's such a big problem for you, I'm sure you will
demonstrate that the first version of your code had _no_ bugs, right?

Oh, wait, you can't, because it did.

Gods, but you're a weenie.

Seebach had one bug in one line of code. At that rate, since I
submitted about 500 lines, I would have had 500 bugs. I had 1% of that
number. Furthermore, the bug was a recruit off-by-one boner, whereas I
had classy and instructive bugs, caused by the fact that unlike any
other poster, I made a genuine effort to use a Boyer/Moore/Knuth et
al. type technique to optimize the search. Even Bacarisse hasn't got
to this point after two plus weeks.

 

[spinoza1111]

[snips]

He doesn't believe that,

In his Annotated C Standard, he says just that, and follows it with the
example of void main().

but most competently written OSen allow you to
declare main in different ways.

I was unaware that OSen defined what constitutes correct C.  You should
let ANSI and ISO know about this.

This isn't what he "believes" in the worst case.

His examples repeatedly demonstrate "Pascal Disease" - read, use value,
_then_ check for EOF.  If he doesn't believe this is the correct method,
why does he use it?

Pascal wasn't a disease. It was a better and more reliable language
than C one which, however, did not allow unethical and incompetent
people to hide their malfeasance and incompetence.

So you're saying he can't read?  After all, he had the very definition of
the mechanics of feof, from the standard itself, right in front of him -
he was, in fact, annotating that very standard.



No, they don't.  Most sane programmers know that *octets* are 8 bits, but
that bytes vary.  Okay, perhaps "sane" isn't the proper term there.  
Perhaps it would be better to say "programmers who haven't spent their
entire lives in the unfounded belief that only one or two familiar CPUs
exist."


There's no particular "dilligence" required to *not* *add* unwarranted
assumptions - such as bytes being 8 bits - to your code.

It's spelled "diligence", Spelling Rainbow (one spelling error is
arguably a typo: two begins to indicate aliteracy). In actuality, it
is silly to write code for things that won't be happening any time
soon.

Golly gee, did I make a typo?

Yes, and one above, so you're well on the way to showing that you're
aliterate. Not illiterate, just contemptuous of the written word. And
yes, "aliterate" is a real word: it started to appear in the New York
Times in the 1980s.

I'm unaware of any such document.  I know at least one - a rather well-
known critique of Schildt's work - which applies the logic "If you're
going to write on a subject, particularly if you're going to write
something akin to a tutorial on it, it's a good idea to have at least a
vague knowledge of the subject matter."

The problem being that Seebach, without academic preparation in
computer science, wasn't qualified to write "C: the Complete
Nonsense", and it's nonetheless become the sole source for attacks on
Schildt, while hundreds of other computer books contain similar
errors...owing to the fact that publishers (as opposed to their
contract authors) have made a business decision, that BECAUSE under
the US uniform commercial code and similar international laws they can
publish bugs, that Herb et al. need not be given enough time.

As Adorno pointed out in his writings on music, capitalism simply
doesn't give people enough time to work when their work cannot be
directly, crudely and brutally related to the profits made by the
super-rich. Adorno noted that even renowned symphony orchestras were
simply not given enough rehearsal time to do a good job: instead they
were given thugs and tyrants like Toscanini as "godlike" conductors.
Likewise, book authors aren't given enough time.

What?  A programmer had a *bug*?  In non-production code?  How shocking.  
After all, no decent programmer would *ever* produce even a single bug in
any piece of code.

Yes. This contradicts the fact that we're supposed to scapegoat Herb.
Why can't we blame Peter for posting a far more idiotic mistake? Could
it be that all one needs to do is establish chops by deliberately
destroying a reputation, whether in some office or online, to be
ourselves above criticism? And is this not the republic of fear?

Sorry, which universe did you say you hail from?

Like Kant or the mighty Klaatu (The Day the Earth Stood Still), I am
probably the citizen of a better world.

Actually, they seem to be an artifact of Schildt's inability to
comprehend even simple things pertaining to C, even when they're right in
front of him.

I'm pretty certain that (1) he comprehends more than you but (2) being
a smart guy, has not elected to become a C specialist. The toxic
effects of specialising in the mistakes of the past are evident in the
stunted personalities in this newsgroup.

We're not discussing "buggy code", we're discussing fundamental errors in
comprehension of simple ideas which are explicitly laid out to the author
at the time of his writing.

But by your logic, Seebie doesn't understand jackshit. If from a bug
we can in Herb's case a generalized incompetence, when in fact the
conditions of book production caused the bug, we can make the
inference with far more validity in Seebie's case, since he was under
no deadline pressure to produce a strlen implementation, but fucked it
up all the same.

In this ng, if like Kenny or myself one hasn't sucked up to the regs,
all mistakes are interpreted as incompetence as in the case of
Herb...who appears to have failed to show up at standards meetings to
which people like Seebie bought their way in and sucked up there.
Whereas in fact we all bring widely varying amounts to these
discussions, not only of competence, but also of time.

To put it in another context, a writer who writes a book on driving a car
_might_ make a brain fart that suggests one should use one's left foot to
control the accelerator, and said brain fart may slip past the editors.  
This is simply being human.

Schildt's errors, by contrast, are more akin to him asserting that the
accelerator is hidden under the back seat and requires a third party, in
the back, to control the speed of the vechicle.  This is not a "bug",
this is a fundamental concept error.


There's a website I ran across a while back, where people post
programming tasks and set rewards for them.  Coders can accept a
"contract", write the code, submit it, collect the reward.

It all sounds good, except for one little detail.  In looking over the
typical "contract" offered, most were in the 20 minute to 1 hour range,
but the offered pay was in the $5 or less range.

Even at 20 minutes, $5 a piece would only amount to $15 per hour, but the
average payout one could expect was more like $5 per hour or less - and
that's if one were particularly lucky.

If people want professional work done, they should expect to pay
professional rates.  If the publishers weren't prepared to do this, guess
what?  They'll end up with something like Schildt's abomination.  And
they did.

No, they wanted him to write on an overly wide range of books because
he was a "name".

Appeal to authority noted.  Schildt's work either stands up to scrutiny
on its own merits, or it doesn't.  If it does, his credentials are
irrlevant; if it doesn't, his credentials are likewise irrelevant.  The
fact is, degrees or no, Schildt's work is bad, bad, horribly bad.

It hasn't been found so by the marketplace, because most people know
that a technical book isn't warrantied to be perfect, so they try
things out to make sure they work. Schildt, as his enemies concede,
knows how to present new ideas to beginning programmers. If those
programmers code void main() on their first job, their mates set them
right on these matters of low level craft. And they are matters of low
level craft because the need for them is set by the corruption of C.

In fact, we should be able to decide on a case by case basis what to
return to the OS.

Actually, no.  The source of the "Schildt Canard" as you call it is
Schildt's own works.  The other document is merely commentary.  If
Schildt's work wasn't so abysmally bad in the first place, the additional
document simply _would not exist_.

If it's "abysmally bad" then so are 90% of computer books and nearly
all computer programs, because in our society, a decision has been
made that we don't have to address software quality. Had such a
decision been made it would have been illegal to use C.

"void main()" and "bytes have 8 bits" and the like are neither matters of
style nor interpretation; they are simply *wrong* within the context of
the C standard, the very thing Schildt's work was commenting upon.

Most bytes in fact have 8 bits, and competent OS writers don't give a
flying **** whether you void main.

Schildt demonstrably doesn't "know C", or he wouldn't make such

Perhaps. But I've clearly demonstrated, in my replace() riposte to
Seebie's incompetent % sign sodomy, that one can suck at C, or know
less than "C experts", and be a great programmer. This is because the
design of C was an adolescent prank which has gotten out of hand.

fundamental errors, particularly with the standard staring him in the
face.  As to the "hundreds more", one might note that the commentary
documentation notes, explicitly, that in many cases, the demonstrated
errrors are repeated throughout Schildt's work, and are simply not
needlessly duplicated in the secondary document - yet are themselves
quite sufficient to account for "hundreds" more errors.


It would be difficult to find one worse.


I don't see how learning one's tools and applyihg them correctly is a
mistaken approach; it is simply one Schildt did not apply.

But that's precisely what people don't do here. They don't "learn"
their tools in the sense of cultivating a critical attitude towards
tools. Instead they substitute tools worship in the manner of the
cargo cult, since this is the required "good attitude" in programming
shops of today, where the most mediocre are given sinecures merely
keeping the existing crap alive, since computing save at the cutting
edge is a mere cost center.

 

[spinoza1111]

I doubt it.


I did not say so. I said they were arbitrarily many and arbitrarily
long, but I did not specify a language.


For example, it might include the full chemical name of titin (189819
letters long). Or it might not.


No, we don't. The file format is fixed by an external constraint. N
lines, each line consisting of a word terminated by a newline character.
If you want a word count, you have to count the words. That's O(N) right
there.




How big? The list is arbitrarily long.

  all


No, because the Standard doesn't guarantee this. If you want an array of
null pointers at startup, you'll have to make it static or put it at
file scope.


At this point, you have read the word, butspinoza1111'sclaim was that
he could store the data *without* reading it.

You are lying in the manner of the structured walkthrough THUG, but it
doesn't work here.

 

[spinoza1111]

[snips]
On Sat, 20 Feb 2010 21:41:00 -0800,spinoza1111wrote:
No, because you've bought a set of trivial truths
Hmm?  Truth - even trivial truth - is now somehow a bad thing?
have gone to McGraw Hill, and lies as being == Schildt who in fact is a
generalist whose enemies concede is "clear", which necessarily means
"understandable", which in turn, necessarily means true.
Say what?
"Dogs are members of the family Felidae".  It's clear, it's
understandable, it's flat-out wrong.
As is Schildt, frequently, in his Annotated C Standard - clear,
understandable, and flat-out wrong.

Spinny, twerp that he is, has had this simple truism explained to him
endless times, but he still doesn't get it.

Reductio:

In C, 0 is false.
A given bit is clear.
Therefore the bit is understandable.

A "bit" is a piece of hardware that used to be a ferrite core
And now is something else: what it is, is a bore,
But whatever it is, it is not an assertion...it is a thing
That used to be an iron ring.

You use sloppy English in the manner of Thugee
A bit is nothing like a statement:
To say "it is zero" when it is not is unclear,
Since it is to make a false statement...we don't know what's meant.

Falsehood is not clarity,
Because in decency and in charity,
We engage in a common search for Truth.

 

[spinoza1111]

I do not recall coining such a term.  I have seen it used, certainly, but I
hardly think I invented it.

It's been removed I see from "C The Complete Nonsense" and wikipedia.
Orwellian. But, it looks like my campaign is slowly having beneficial
results.

This kind of thing contributes to your difficulty persuading people that
you are in any way something other than a kook.

I'm not a kook, but I am an Apress colleague of yours, and you're not
doing Apress any help with these attacks...against which I will defend
myself, if necessary, by exposing your own errors ("the 'heap' is a
DOS term": "hey watch me implement strlen") at every turn. I'm
thinking of buying your book and finding its errors in turn, because
you need to be educated in the fact of limited resources, collegiality
and decency. As a book author, you need to learn a basic business
lesson: DON'T "knock" the competition, instead concentrate on self-
improvement (such as taking those CS classes you missed).

 

[spinoza1111]

On 21/02/2010 22:25, Kelsey Bjarnason wrote:

[snips]
On Sat, 20 Feb 2010 21:41:00 -0800,spinoza1111wrote:
No, because you've bought a set of trivial truths
Hmm?  Truth - even trivial truth - is now somehow a bad thing?
have gone to McGraw Hill, and lies as being == Schildt who in fact is a
generalist whose enemies concede is "clear", which necessarily means
"understandable", which in turn, necessarily means true.
Say what?
"Dogs are members of the family Felidae".  It's clear, it's
understandable, it's flat-out wrong.

Not as a speech act. Grownups, engaged in civil discourse, endeavor to
discover why the above statement is being made. Children, on the other
hand, are used to being lied to.



I've already explained that: clarity is understandability (as you
concede) but "understanding" is "knowledge", and knowledge is
justified belief in things that are true. Therefore, because Schildt
is clear, he is understandable, and if he is understandable, he giveth
understanding, and the understanding that he giveth can be naught else
than knowledge, the justified belief in aught that is true and naught
that is false. Let this be a lesson unto ye.

In fact, only a clumsy writer would have said up front, as Seebie-
Weebie said, that Herb is "clear". Shot himself in the foot he did. I
would have written "Herb's texts have only an apparent clarity" in
Churchillian tones, going on to say,

"This clarity is marred by clarity's enemy, which is error. Members of
this House are reminded that we may not say with sense, that the
leader of the opposition party is 'clear' when in one speech, he makes
such egregious errors on the situation of our forces in South Africa,
therefore I demur from my respected fellow Party member's opinion,
that the Prime Minister was 'clear' but 'wrong'."

"In fact, his Grace was unclear to the charitable and enlightened
section of opinion, which in a Liberal spirit reaches across the
sword's length of this House and endeavors, so far as it is able, to
find truth in error, and sound policy in misadventure. Try as we
might, like the Hindoo fakir endeavoring to find sound advice in his
Sans-crit text amidst lurid folly, Asiatic extravagance, and wearisome
prolixity, we cannot put a sensible construction on this Government's
intentions and policy, and must therefore call that policy a fog, a
fug, a mist, and most unclear."

Growls of approval, and cries of hear! hear!.
Calls for order from the Speaker:
Howls of dismay from the dogs so drear
Approbation from Truth's noble seeker.
The voice of wisdom and right
Is never at first, seen in plain sight:
It must raise its voice in the middle of the fight.

 

[spinoza1111]

spinoza1111wrote:


Yes, but possibly not in the way you intend. Your continual defence of
the indefensible simply exposes more and more of the problems in
Schildt's writings to those who might not otherwise have been aware of
them. This is a Good Thing - in fact, it is possibly the most useful
thing you've ever done.

These problems do not only exist in Schildt's books, they are
characteristic of the genre, and you are scapegoating Schildt. Your
own book contains the absurd idea that a tool that unnecessarily
copies O(N) where N is unpredictable, and I am certain that if I audit
your book with anything like the attention given to Herb, I will find
many, many more errors, probably more than Schildt because of your
lack of the computer science education he has, and which is evident in
your linked list solution.

Keep saying it, keep believing it. It may come true one day. And even if
it doesn't, it's still a worthy goal to aim for.

**** you, asshole.

 

[blmblm]

...code...

I noticed that in the latest (13 Feb) version of the code, with the
fix to the one-character replace found by Ben B, there were some file
nits: two long lines split and blanks at end of continued macro lines.

Let's see if I can get rid of these problems.

Also, I misspoke. The failure to handle Ben's example was caused by an
earlier change.

Here is the latest code, without the console output.

I believe you may still have a bug. When I extracted your replace
function in order to include it in my set of performance experiments
and compiled with gcc -Wall -pedantic -std=c99, I got some warnings
that the following variables "may be used uninitialized":

ptrSegmentStructStarts
ptrIndex3
ptrIndex2

and when I ran your tests, the one with an empty input string
crashed. Running the code in gdb .... To make a longish
story short, it appears to me that under these circumstances
ptrSegmentStructStarts does not get properly initialized.
Giving it an initial value of NULL (by adding = NULL to the
declaration) seemed to resolve the problem.

I make no claims about understanding your code -- my goal was
simply to make sure it passed your tests before trying my timing
tests, and I have a lot of practice with "fixing" other people's
code without mastering all its details [*] -- so you may have a
better fix.

It doesn't surprise me much that I found this apparent bug and
you didn't -- it seems like something that might show up, or not,
depending on a lot of platform-specific things. I *am* mildly
curious, though, about whether whatever compiler you used warned
you about variables not being initialized.

For what it's worth.

[*] This was a valuable skill in a previous day job (doing
maintenance/enhancement programming) and has been an asset in
my current day job (teaching undergrad CS courses) as well.
It does have rather a feel of shoddy engineering about it,
but -- eh, tradeoffs.

[ snip ]

 

[Nick]

[snips]

No, because you've bought a set of trivial truths

Hmm? Truth - even trivial truth - is now somehow a bad thing?

have gone to McGraw Hill, and lies as being == Schildt who in fact is a
generalist whose enemies concede is "clear", which necessarily means
"understandable", which in turn, necessarily means true.

Say what?

"Dogs are members of the family Felidae". It's clear, it's
understandable, it's flat-out wrong.

As is Schildt, frequently, in his Annotated C Standard - clear,
understandable, and flat-out wrong.

Spinny, twerp that he is, has had this simple truism explained to him
endless times, but he still doesn't get it.

It was indeed this astonishing failure to comprehend that things can be
clear yet wrong that lead me to plonk him. Arguing with someone who
doesn't speak the same language is never going to be productive.

 

[blmblm]

If you're going to be so petty as to flame misspellings, you lay
yourself open to equally petty charges, such as misquoting (the quote
above has elided spaces from the text I actually wrote).

I think the missing spaces are an artifact of Google's posting
interface; I've seen this same glitch in other postings from GG
users, and I think it has something to do with whatever Google is
doing to try to hide/mask e-mail addresses. Just sayin'.

[ snip ]

 

[Phil Carmody]

Priceless ;-)

No. Worthless. Learn the difference, and evolve the ability to use
a killfile. Please.

Phil

 

[Phil Carmody]

[..] quote above has elided spaces from the text I actually wrote).

I think the missing spaces are an artifact of Google's posting [...]

Sure, but would you not agree that a poster bears responsibility for
what he posts? If a newsreader is corrupting articles, the responsible
poster has some choices:

(a) accept responsibility for the corruption;
(b) fix the newsreader;
(c) get someone else to fix the newsreader;
(d) use a different newsreader.

(Did I miss any?)

(e) Modify what's posted so that it doesn't get so mangled. I often
see small code snippets exchanged with a dummy first column so that
leading spaces aren't binned, for example. Fortunately faux patch(1)s
work perfectly for that task.

(f) Nuke googlegroups from orbit, it's the only way to be sure. (OK,
not a complete solution to this particular problem, but a complete
solution to many other problems, and at least a partial one to the above.)

Phil

 

[spinoza1111]

[snips]
On Sat, 20 Feb 2010 21:41:00 -0800,spinoza1111wrote:
No, because you've bought a set of trivial truths
Hmm?  Truth - even trivial truth - is now somehow a bad thing?
have gone to McGraw Hill, and lies as being == Schildt who in fact is a
generalist whose enemies concede is "clear", which necessarily means
"understandable", which in turn, necessarily means true.
Say what?
"Dogs are members of the family Felidae".  It's clear, it's
understandable, it's flat-out wrong.
As is Schildt, frequently, in his Annotated C Standard - clear,
understandable, and flat-out wrong.

Spinny, twerp that he is, has had this simple truism explained to him
endless times, but he still doesn't get it.

It was indeed this astonishing failure to comprehend that things can be
clear yet wrong that lead me to plonk him.  Arguing with someone who
doesn't speak the same language is never going to be productive.

....and we must be productive, chillens. OK, I am not gwine be
productive (of crap), because in fact, as a careful (and published)
writer, I would never shoot myself in the foot by saying that someone
is "clear but wrong".

 

[spinoza1111]

...code...

I noticed that in the latest (13 Feb) version of the code, with the
fix to the one-character replace found by Ben B, there were some file
nits: two long lines split and blanks at end of continued macro lines.

Let's see if I can get rid of these problems.

Also, I misspoke. The failure to handle Ben's example was caused by an
earlier change.

Here is the latest code, without the console output.

I believe you may still have a bug.  When I extracted your replace
function in order to include it in my set of performance experiments
and compiled with gcc -Wall -pedantic -std=c99, I got some warnings
that the following variables "may be used uninitialized":

ptrSegmentStructStarts
ptrIndex3
ptrIndex2

and when I ran your tests, the one with an empty input string
crashed.  Running the code in gdb ....  To make a longish
story short, it appears to me that under these circumstances
ptrSegmentStructStarts does not get properly initialized.
Giving it an initial value of NULL (by adding = NULL to the
declaration) seemed to resolve the problem.

I make no claims about understanding your code -- my goal was
simply to make sure it passed your tests before trying my timing
tests, and I have a lot of practice with "fixing" other people's
code without mastering all its details [*] -- so you may have a
better fix.  

It doesn't surprise me much that I found this apparent bug and
you didn't -- it seems like something that might show up, or not,
depending on a lot of platform-specific things.  I *am* mildly
curious, though, about whether whatever compiler you used warned
you about variables not being initialized.

For what it's worth.

[*] This was a valuable skill in a previous day job (doing
maintenance/enhancement programming) and has been an asset in
my current day job (teaching undergrad CS courses) as well.
It does have rather a feel of shoddy engineering about it,
but -- eh, tradeoffs.

[ snip ]

Thanks for finding this bug, Professor!

Yes, you are correct. I did not initialize the ptrSegmentStructStarts
pointer and the program failed on a null master string. Since it is
without meaning to search for a null target, I'd inserted a check for
a null target, but a search in a null master is correct.

I'd been laboring under an incorrect presumption, which was that the
dialect of C supported by Microsoft C++ Express .Net in C mode does
not support variable initialization, therefore I'd initialized
selectively and "by hand". I was also mistakenly under the impression
that the pointer would get initialized inside the loop the first time
a structure instance is created but NO instances need be created, nor
are created, for null masters.

The fix was to insert an initial value in ALL declarations and I will
do so henceforth.

Here is the code with you credited in the Change Record, followed by
the console output.

Thanks again.

// ***************************************************************
// * *
// * replace() demo *
// * *
// * Demonstrates how to replace non-NUL-defined strings in C *
// * using a simple function, and bypassing string.h. *
// * *
// * C H A N G E R E C O R D --------------------------------- *
// * DATE PROGRAMMER DESCRIPTION OF CHANGE *
// * -------- ---------- --------------------------------- *
// * 02 07 10 Nilges Version 1.0 *
// * *
// * 02 07 10 Nilges Bug: partial matches not handled *
// * correctly: need to iterate search *
// * for match. *
// * *
// * 02 07 10 Nilges 1. Santosh suggested tests *
// * 2. Heathfield put the boot in re *
// * including malloc *
// * *
// * 02 07 10 Nilges 1. Remove string.h use and code *
// * strlen by hand *
// * 2. Add comment block and comments*
// * inline. *
// * 3. free() storage *
// * 4. Use macro for testing *
// * 5. Bug: calculation of *
// * lngNewLength used incorrect *
// * index (intIndex3 instead of 2)*
// * which caused a memory leak. *
// * *
// * 02 07 10 Nilges 1. Bug: Ike Naar test failed. *
// * At end of scan loop, main *
// * string pointer was not *
// * correctly updated from index3 *
// * *
// * 02 07 10 Nilges Added new Santosh test *
// * *
// * 02 07 10 Nilges Added new Ike Naar test *
// * *
// * 02 08 10 Nilges 1. Added some new comments *
// * 2. Make "check for a complete *
// * match "structured" by means *
// * of a tested assignment *
// * 3. Get rid of "replace at end" *
// * evilness: the only time this *
// * flag is meaningful is in the *
// * LAST segment. *
// * 4. Return replace count *
// * 5. TESTER macro assertion added *
// * *
// * 02 10 10 Nilges 1. Bug fix: in a partial match, *
// * the main scan index is set to *
// * one past the end, which misses*
// * full matches that start *
// * between the first character of*
// * the partial match and its end.*
// * *
// * No longer updating the main *
// * scan index (ptrIndex1) to the *
// * point of partial match *
// * failure: setting it one past *
// * the first character of the *
// * partial match. *
// * *
// * 2. Line up expected & actual *
// * results per excellent *
// * suggestion (who made this?) *
// * *
// * 3. After a partial match, update *
// * the main handle search index *
// * (ptrIndex1) to the first *
// * occurrence of the handle *
// * character after the start of *
// * the partial match, or to the *
// * index of the unmatched char. *
// * *
// * 02 22 10 Nilges 1. Bug fix: pointer to start of *
// * list is not initialized but is*
// * used when the master string is*
// * null. *
// * *
// * Added initializations to all *
// * declarations. *
// * *
// * Thanks to Prof. Massingill for*
// * finding the bug. *
// * *
// * ----------------------------------------------------------- *
// * *
// * "In the near future we shall have to live with the *
// * superstition that programming is 'so easy that even a *
// * Republican can do it!'" *
// * *
// * - E. W. Dijkstra *
// * *
// * *
// ***************************************************************
#include <stdio.h>
#include <stdlib.h>
// ***** Segmentation *****
struct TYPsegmentstruct
{ char * strSegment;
long lngSegmentLength;
struct TYPsegmentstruct * ptrNext; };
// ---------------------------------------------------------------
// Calculate string length
//
//
long strLength(char *strInstring)
{
char *ptrInstring = strInstring;
for (; *ptrInstring; ptrInstring++);
return ptrInstring - strInstring;
}

// ---------------------------------------------------------------
// Replace target by replacement string in master string
//
//
// Caution: the string returned by this function should be freed.
//
//
char * replace(char * strMaster,
char * strTarget,
char * strReplacement,
long * ptrReplacements)
{
char * ptrIndex0 = 0;
char * ptrIndex1 = 0;
char * ptrIndex2 = 0;
char * ptrIndex3 = 0;
char * ptrIndex4 = 0;
char * strNew = 0;
char * strNewStart = 0;
long lngNewLength = 0;
long lngCount = 0;
long lngReplacementLength = 0;
struct TYPsegmentstruct * ptrSegmentStructStarts = 0;
struct TYPsegmentstruct * ptrSegmentStruct = 0;
struct TYPsegmentstruct * ptrSegmentStructPrev = 0;
lngReplacementLength = strLength(strReplacement);
if (!*strTarget)
{
printf("Error in calling replace(): target can't be null");
abort();
}
ptrIndex1 = strMaster;
ptrSegmentStructPrev = 0;
lngNewLength = 0;
*ptrReplacements = 0;
while(*ptrIndex1)
{
ptrIndex0 = ptrIndex1;
while (-1)
{
// --- Check for (one character) handle
for(;
*ptrIndex1 && *ptrIndex1 != *strTarget;
ptrIndex1++);
// --- Check for complete match while remembering the
// --- last position of the handle
ptrIndex4 = 0;
for(ptrIndex2 = strTarget + 1,
ptrIndex3 = ptrIndex1 + 1;
*ptrIndex3
&&
*ptrIndex2
&&
*ptrIndex3 == *ptrIndex2;
ptrIndex3++, ptrIndex2++)
{
if (*ptrIndex3 == *strTarget
&&
ptrIndex4 == 0) ptrIndex4 = ptrIndex3;
}
// End test: check complete match, update main ptr past
// partial match while checking for end of loop
if ((!*ptrIndex2 ? ((*ptrReplacements)++, -1) : 0)
||
(!*ptrIndex3 ? (ptrIndex1 = ptrIndex3, -1) : 0))
break;
// Update the main search pointer
ptrIndex1 = (ptrIndex4 == 0 ? ptrIndex3 : ptrIndex4);
}
// --- Create new segment
if (!(ptrSegmentStruct =
malloc(sizeof(struct TYPsegmentstruct))))
abort();
ptrSegmentStruct->strSegment = ptrIndex0;
ptrSegmentStruct->lngSegmentLength =
ptrIndex1 - ptrIndex0;
ptrSegmentStruct->ptrNext = 0;
if (ptrSegmentStructPrev != 0)
ptrSegmentStructPrev->ptrNext = ptrSegmentStruct;
else
ptrSegmentStructStarts = ptrSegmentStruct;
ptrSegmentStructPrev = ptrSegmentStruct;
// --- Update mallocation length
lngNewLength += ptrSegmentStruct->lngSegmentLength +
(!*ptrIndex2
?
lngReplacementLength
:
0);
// --- Get past end of target string & iterate
ptrIndex1 = ptrIndex3;
}
// --- Allocate just enough storage for the new string
if (!(strNewStart = malloc(lngNewLength + 1))) abort();
// --- Build the new string whilst freeing the list
strNew = strNewStart;
ptrSegmentStruct = ptrSegmentStructStarts;
while (ptrSegmentStruct)
{
for (ptrIndex1 = ptrSegmentStruct->strSegment,
lngCount = 0;
lngCount < ptrSegmentStruct->lngSegmentLength;
ptrIndex1++, lngCount++, strNew++)
*strNew = *ptrIndex1;
if (ptrSegmentStruct->ptrNext || !*ptrIndex2)
for (ptrIndex1 = strReplacement;
*ptrIndex1;
ptrIndex1++, ++strNew)
*strNew = *ptrIndex1;
ptrSegmentStructPrev = ptrSegmentStruct;
ptrSegmentStruct = ptrSegmentStruct->ptrNext;
free(ptrSegmentStructPrev);
}
*strNew = '\0';
return strNewStart;
}

// ---------------------------------------------------------------
// Statement-format test macro
//
//
#define TESTER(resultPtr, master, target, replacement, expected,
expectedReplacements, replacements) \
{ \
printf("Replace \"%s\" by \"%s\" in \"%s\"\n", \
(target), (replacement), (master)); \
printf("Expect \"%s\":\n \"%s\"\n", \
(expected), \
resultPtr = replace((master), \
(target), \
(replacement), \
&(replacements))); \
printf("Replacements expected: %d: replacements: %d\n", \
(expectedReplacements), \
(replacements)); \
if (!(strLength(resultPtr) \
== \
strLength(master) \
+ \
(strLength(replacement)-strLength(target)) \
* \
replacements)) \
printf("Assertion failed\n"); \
printf("\n\n"); \
free(resultPtr); \
}

// ---------------------------------------------------------------
// Main procedure
//
//
int main()
{
char *ptrResult;
long lngReplacements;
printf("\nReplace version as of 1910 22 Feb\n\n\n");
TESTER(ptrResult,
"",
"111123",
"ono",
"",
0,
lngReplacements)
TESTER(ptrResult,
"1111123bbb1111123bbb11123bb11111231111112111111123",
"111123",
"ono",
"1onobbb1onobbb11123bb1ono1111112111ono",
4,
lngReplacements)
TESTER(ptrResult,
"bbb1111123bbbbb",
"111123",
"ono",
"bbb1onobbbbb",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid error",
"stupid error",
"miracle",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid error",
"stupid",
"miracle",
"a miracle error",
1,
lngReplacements)
TESTER(ptrResult,
"the stupid error",
"the stupid error",
"a miracle",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"the miracle",
"the",
"a",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a miraclsnirpKamunkle",
"snirpKamunkle",
"e",
"a miracle",
1,
lngReplacements)
TESTER(ptrResult,
"a miraclesnirpKamunkle",
"a miracle",
"",
"snirpKamunkle",
1,
lngReplacements)
TESTER(ptrResult,
" a miraclesnirpKamunkle",
"a miracle",
"",
" snirpKamunkle",
1,
lngReplacements)
TESTER(ptrResult,
" a miraclesnirpKamunklea miraclea miracle",
"a miracle",
"",
" snirpKamunkle",
3,
lngReplacements)
TESTER(ptrResult,
"a miracle a miraclesnirpKamunkle a Miraclea miraclea
miracle",
"a miracle",
"",
" snirpKamunkle a Miracle",
4,
lngReplacements)
TESTER(ptrResult,
"a stupid errord",
"stupid error",
"miracle",
"a miracled",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid errod",
"stupid error",
"miracle",
"a stupid errod",
0,
lngReplacements)
TESTER(ptrResult,
"a sstupid error",
"stupid error",
"miracle",
"a smiracle",
1,
lngReplacements)
TESTER(ptrResult,
"a stupid errorstupid error",
"stupid error",
"miracle",
"a miraclemiracle",
2,
lngReplacements)
TESTER(ptrResult,
"a stupid error stupiderror",
"stupid error",
"miracle",
"a miracle stupiderror",
1,
lngReplacements)
TESTER(ptrResult,
"bbbbbbbbbb",
"b",
"a",
"aaaaaaaaaa",
10,
lngReplacements)
TESTER(ptrResult,
"In the halls of R'yleh great %s lies dreaming",
"%s",
"Cthulu",
"In the halls of R'yleh great Cthulu lies dreaming",
1,
lngReplacements)
TESTER(ptrResult,
"%s%s%s%s%s%s",
"%s",
"Cthulu",
"CthuluCthuluCthuluCthuluCthuluCthulu",
6,
lngReplacements)
TESTER(ptrResult,
"banana",
"ana",
"oat",
"boatna",
1,
lngReplacements)
TESTER(ptrResult,
" a stupid errorstupid errorHeystupid errors",
"stupid error",
"+",
" a ++Hey+s",
3,
lngReplacements)
TESTER(ptrResult,
"foo barfoo barf",
"foo bar",
"bas",
"basbasf",
2,
lngReplacements)
TESTER(ptrResult,
"abab",
"ba",
"ba",
"abab",
1,
lngReplacements)
TESTER(ptrResult,
"abab",
"bab",
"boop",
"aboop",
1,
lngReplacements)
TESTER(ptrResult,
"banana",
"ana",
"ono",
"bonona",
1,
lngReplacements)
printf("\n\nTesting complete: check output carefully: \"Assertion
failed\" should not occur!\n\n");
return 0;
}


Replace version as of 1910 22 Feb


Replace "111123" by "ono" in ""
Expect "":
""
Replacements expected: 0: replacements: 0


Replace "111123" by "ono" in
"1111123bbb1111123bbb11123bb11111231111112111111123"
Expect "1onobbb1onobbb11123bb1ono1111112111ono":
"1onobbb1onobbb11123bb1ono1111112111ono"
Replacements expected: 4: replacements: 4


Replace "111123" by "ono" in "bbb1111123bbbbb"
Expect "bbb1onobbbbb":
"bbb1onobbbbb"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "stupid" by "miracle" in "a stupid error"
Expect "a miracle error":
"a miracle error"
Replacements expected: 1: replacements: 1


Replace "the stupid error" by "a miracle" in "the stupid error"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "the" by "a" in "the miracle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "snirpKamunkle" by "e" in "a miraclsnirpKamunkle"
Expect "a miracle":
"a miracle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in "a miraclesnirpKamunkle"
Expect "snirpKamunkle":
"snirpKamunkle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in " a miraclesnirpKamunkle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 1: replacements: 1


Replace "a miracle" by "" in " a miraclesnirpKamunklea miraclea
miracle"
Expect " snirpKamunkle":
" snirpKamunkle"
Replacements expected: 3: replacements: 3


Replace "a miracle" by "" in "a miracle a miraclesnirpKamunkle a
Miraclea miraclea miracle"
Expect " snirpKamunkle a Miracle":
" snirpKamunkle a Miracle"
Replacements expected: 4: replacements: 4


Replace "stupid error" by "miracle" in "a stupid errord"
Expect "a miracled":
"a miracled"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid errod"
Expect "a stupid errod":
"a stupid errod"
Replacements expected: 0: replacements: 0


Replace "stupid error" by "miracle" in "a sstupid error"
Expect "a smiracle":
"a smiracle"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "miracle" in "a stupid errorstupid error"
Expect "a miraclemiracle":
"a miraclemiracle"
Replacements expected: 2: replacements: 2


Replace "stupid error" by "miracle" in "a stupid error stupiderror"
Expect "a miracle stupiderror":
"a miracle stupiderror"
Replacements expected: 1: replacements: 1


Replace "b" by "a" in "bbbbbbbbbb"
Expect "aaaaaaaaaa":
"aaaaaaaaaa"
Replacements expected: 10: replacements: 10


Replace "%s" by "Cthulu" in "In the halls of R'yleh great %s lies
dreaming"
Expect "In the halls of R'yleh great Cthulu lies dreaming":
"In the halls of R'yleh great Cthulu lies dreaming"
Replacements expected: 1: replacements: 1


Replace "%s" by "Cthulu" in "%s%s%s%s%s%s"
Expect "CthuluCthuluCthuluCthuluCthuluCthulu":
"CthuluCthuluCthuluCthuluCthuluCthulu"
Replacements expected: 6: replacements: 6


Replace "ana" by "oat" in "banana"
Expect "boatna":
"boatna"
Replacements expected: 1: replacements: 1


Replace "stupid error" by "+" in " a stupid errorstupid errorHeystupid
errors"
Expect " a ++Hey+s":
" a ++Hey+s"
Replacements expected: 3: replacements: 3


Replace "foo bar" by "bas" in "foo barfoo barf"
Expect "basbasf":
"basbasf"
Replacements expected: 2: replacements: 2


Replace "ba" by "ba" in "abab"
Expect "abab":
"abab"
Replacements expected: 1: replacements: 1


Replace "bab" by "boop" in "abab"
Expect "aboop":
"aboop"
Replacements expected: 1: replacements: 1


Replace "ana" by "ono" in "banana"
Expect "bonona":
"bonona"
Replacements expected: 1: replacements: 1




Testing complete: check output carefully: "Assertion failed" should
not occur!

 

[spinoza1111]

spinoza1111wrote:


That is, unfortunately, quite true. Perhaps someone will take up the
burden of documenting other authors' errors (where the authors
themselves have not done so).


No, I don't think so.


Huh? I can't parse that. You appear to have omitted a word, but I can't
tell which one. If you would care to explain what you mean more
precisely, I will explain why you are wrong. If you simply mean that the
idea of a container is absurd, then you are wrong for the obvious reason
that the idea of a container is not absurd.

(Sigh)

(Eye roll)

(Crotch grab)

Your "linked list" tool copies node values unnecessarily into each
node, where competent individuals set the node to point to the data,
so that node creation doesn't take unpredictable amounts of time
depending on the size of the data. Computer Science 101.

Feel free to try finding C errors in my book. It's not difficult. In
fact, many of them have already been documented (mostly but not solely
by me) on the book's current errata page, so you're off to a flying
start. If you can find a C error that hasn't already been documented and
that is actually a genuine C error (as opposed to a diseased imagining

It's not "diseased imagining" to expect you to know how to construct a
simple linked list O(1).

based on your misunderstanding of C), I'll be surprised, but not unduly

What's my "misunderstanding"? That "knowing" the mistakes of C is
competence, and can replace computer science awareness?

 

[Ike Naar]

No. Worthless. Learn the difference, and evolve the ability to use
a killfile. Please.

Done. Bye.

 

[Nick Keighley]

Heathfield wrote a "linked list tool"
without pointing to data,
[...] my point was that the DATA in the list is the DATA and
not a link, and nobody with a halfway decent education in data
structures would have proposed such a stupid design, save, perhaps,
for a linked list of data elements whose type is simple and fixed in
length...not a "reusable tool".
Alex Stepanov, the designer of the C++ STL library is untutored in
[computer science?] [this line reinserted]

note the question mark! See furthur down in this post for my take on
this.

Did you read Nick's whole sentence before starting to type your
response?  he said

it was a rhetorical question. The C++ Standard template Library is
generally regarded as quite impressive. And Alex Stepanov is generally
regarded as a pretty substantial computer scientist. The STL is
"value" based (this is nothing to do with "values" in the moral or
ethical sense) and copies things.

I was using the STL of an example of a well known and usually highly
regarded generic library that copies things. I really don't understand
how you could fail to understand my point!

which to me says nothing at all about whether he thinks Stepanov
is "untutored in computer science", but is instead an attempt to
suggest that if Heathfield's approach is indeed faulty, he's in
good company.

exactly backwards!

(And you even retained the text ....  "Whatever", maybe.)

que?

 

[Nick Keighley]

I would not dignify Heathfield as "value based". Instead, I think he
didn't know how to do the job, since to do it you have to use the
preprocessor *safely* to abstract the node pointer type.

I was making the point that Richard Heathfield's /library/ was value
based, not Richard himself.