Re: [EGN] Variable hoisting

From: Programmer Dude (Chris_at_Sonnack.com)
Date: 09/10/04


Date: Fri, 10 Sep 2004 12:48:42 -0500

More Edward G. Nilges lies....

>> 2. In fact, I found a couple bugs, one I considered a typo (and note
>> that the code style was so bad that this was missed by not only
>> the original author, but also by a C expert (Richard)). The other
>> very serious bug--a major design error--required two years for the
>> author to even acknowledge.
>
> This is a lie.

The facts are easily verified. The public record *exists* for all.

> This bug was found and fixed by me the same evening in May 2002 I
> posted the code,

In your dreams, perhaps. Let's review the public record once again
(yes, I know we did this just last June....now it needs doing again).

Doubting parties may use the date/time to locate the referenced posts
in Goggle or the archive of your choice.....

BEGIN REPOST OF JUNE 2004 POST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Wed, 26 Jun 2002 16:19:37

[Ed posts his C code string tokenizer...]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subject; Re: The Data Quality Act
   Date; Thu, 27 Jun 2002 15:10:57

I spent a hour or so re-writing the C version to what I would
consider good C practice (and per my own style just for example).
In the process I found a SERIOUS bug in the C code. It occurs on
line 131 of the C text, in the main parse function:
[...]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Ed still in denial two days later...]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 12:33:39

CS> The allocated string has no room for the trailing nul.

RH> Sorry for missing this during my own review.

EN> You missed it because you know C and it isn't there.

Sorry, Ed, you're in *serious* denial here. There are two major
bugs in your "parsing" function. The first is exactly what I said
it is, and I'll go over it more carefully for you. [..snip...]

> You appear not to have done your homework, for if the bug had been
> in the original it would have blown up immediately, and you did not
> bother to test your proposed code scrap.

Guess what, Ed. I loaded your original, unmodified (mod line wrapping)
source into VC++ and it DOES crash reporting:

    +--------------------------------------------------+
    | DEBUG ERROR! |
    | Program: Test-D.exe |
    | DAMAGE: after Normal block (#40) at 0x00300150 |
    | (Press Retry to debug the application) |
    | |
    | [Abort] [Retry] [Ignore] |
    +--------------------------------------------------+

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Still swimming in De Nile...]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 18:16:52

> Dude claimed a bug which I have checked out and there is no bug in
> this code:
> [...]

[NOTE THIS: two days later, contrary to recent revisionist attempts
by Ed, the reality was that at the time he (A) claimed to have checked
the code and (B) denied any bug existed.]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Finally Ed begins to acknowledge there "may" be a bug...]

Subject; Re: The Data Quality Act
   Date; Fri, 28 Jun 2002 18:24:17

> This MAY be a genuine bug.

No MAY about it.

[...]

> I think having written this that you probably ARE wrong, but I am
> going to take your post home. You were certainly wrong on the null
> length issue and at best are 1 for two down.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Finally, four days later, Ed acknowledges (NOT FIXES)...]

Subject; Re: The Data Quality Act
   Date; Sun, 30 Jun 2002 23:24:16

> OK. It appears that the malloc needed to malloc one more byte.

Yes.

> Chris is probably one for two since I believe a null string with a
> string delim is handled.

I'm afraid the other bug still exists. It has to do with what happens
with you "parse" a string using string delimiting, but the string has
no delimiter present.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[Still no acknowledgement of error or simple test cases...]

Subject; Re: The Data Quality Act
   Date; Tue, 09 Jul 2002 17:05:02

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[And STILL not...]

Subject; Re: The Data Quality Act
   Date; Thu, 11 Jul 2002 13:06:19

> I think the problem is that I presented end-to-end solutions which
> worked the first time out,...

No, they didn't. Your C solution crashed immediately and refused
to run until I fixed your error. Even then it produced erroneous
results due to the other bug. That's two major bugs in the single
function of substance in your C solution.

Your VB solution at least runs, but it's poorly designed--particularly
for a tool object. Worse, I say it ALSO produces erroneous results:

For the string: ",Moe,,Larry,Curley,,Shemp,Curley-Joe,CurleyJoeBesser,"

[NOTE: That was YOUR test string, Ed.]

Your VB routine claims there are *nine* tokens. Do you feel there
should be a (blank) token *after* the final comma? That would make
10 tokens...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[June this year, years later, finally (after asking a dozen times):]

CS> ..how many fields in the following CSV: ",John,,Rogar,Mick,"

EN> There are duh six fields in the string.

Exactly. So why did both your programs report five?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
END REPOST OF JUNE 2004 POST

So there it is, Ed. Proof once again that you are either insane or
a very bad, very bald liar.

>> 1. My opinion of the coding style was a trivial matter mentioned in
>> passing. An mature adult programmer would have taken it for what
>> it was and moved on, not obsessed over it for years.
>
> Incorrect. You used trivial and personal rules about coding style as a
> basis for a personal offensive because you were being emotionally
> manipulated by Richard Heathfield.

Another lie. The record above shows exactly what I said.

> Of course, I welcomed constructive dialog NOT based on emotional
> manipulation by strangers working perhaps for anti-labor organizations
> and I've frequently engaged in collegial dialog.

I doubt it. Your track record here is clear.

> A characteristic of such dialog is studied lack of anxiety about
> whether one is an "incompetent" and a sign of this lack is that
> psychological transference in the form of the charge of "incompetence"

Amazed me how you can write this apparently not recogizing that this is
exactly *your* tactic, Ed. If you lack anxiety about your obvious lack
of competence, why are you still obsessing over comments made over two
years ago?

Clearly you feel threatened, and rightfully so. Any good programmer
*would* be a threat to you.

And note how often you accuse others of incompetence and ignorance.
Just as you say above.

Difference is, we know what's right and your accusations matter to us
about as much as dog farts (which is to say that they smell foul, but
quickly dissipate and are forgotten).

>> 5. The author posted two versions, a C version whipped up in haste to
>> further his agenda and a VB version--from the author's library of
>> code, his ironically named "PowerString". Both contained serious
>> design errors that caused erroneous results for certain input. I
>> posted a VB version that delivered correct results and performed
>> up to 40 times faster.
>
> In a collegial exchange, not based on deciding the zero-sum
> proposition "I'm a competent programmer and you're not", I would have
> been interested in Chris' changes.

I would have offered--and have to co-workers--the exact same critique.
(THEY weren't so threatened, though.)

> As such, Chris committed theft of intellectual property and stolen
> product including the notion of a power string in the first place now
> decorates his Web site.

Ed,.... your claims of theft are just more dog farts.

And your public attempts at programming are indeed on display as an
example of truly god-awful programming technique. Anyone with a
morbid interest in defective code can view it here:

http://www.sonnack.com/Chris/Software/Code/Toking/index2.html

In particular, viewers might find Ed's original (nilges_original.c)
interesting to compare to the full re-write (nilges_rewrite.c). If
you were a maintance programmer, which version would YOU prefer???



Relevant Pages

  • Re: Chris Sonnack on VB.Nets putative Set statement
    ... A bald-faced lie. ... Re: The Data Quality Act ... In the process I found a SERIOUS bug in the C code. ... CS> The allocated string has no room for the trailing nul. ...
    (comp.programming)
  • Re: Bug analysis
    ... char *ReadTextFile ... The writer of this code is an experienced C programmer. ... has this bug, that is a classical bug with zero terminated strings, ... in the implementation of the string library in lcc-win you ...
    (comp.lang.c)
  • Re: Bug analysis
    ... char *ReadTextFile ... has this bug, that is a classical bug with zero terminated strings, ... programmer has less bug surface. ... in the implementation of the string library in lcc-win you ...
    (comp.lang.c)
  • Re: PLEASE READ (was Re: recursive proofs)
    ... Re: The Data Quality Act ... Note in both cases, "Look, Ma, no string limits!" ... The lack of comments is one reason I'm not going to bother wading ... In the process I found a SERIOUS bug in the C code. ...
    (comp.programming)
  • Re: OT (was: Re: Letter to US Sen. Byron Dorgan re unpaid overtime)
    ... time-complexity involved in repeatedly calculating the length of a string), ... if Jos Horsmeier or Programmer Dude were to state something that I ... You wouldn't know good reasoning if it bit you on the nose (which, ... If you make a mistake and then say "oops", then nobody cares two hoots about ...
    (comp.programming)