My apologies for flooding this newsgroup...
Chris Thomasson
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6c6fe13d14bf0d5a
The ignorance in that thread is abundant indeed. For instance, read the
following post:
"Pops" does not check error return values and mutates data-structures under
read-locks...
I argued with him for a while... Sorry about that.
He is a clear idiot, and I still tried to make my point...
I apologize for cast my pearls before swine.
--
Chris M. Thomasson
http://appcore.home.comcast.net
Chris Thomasson
news:yIOdnchLRblOw6ra...@comcast.com...
> WRT this thread:
>
>
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6c6fe13d14bf0d5a
>
>
>
> The ignorance in that thread is abundant indeed. For instance, read the
> following post:
http://groups.google.com/group/comp.programming.threads/msg/97255a61211b57ad
(relevant part toward end of message...)
Sorry for forgetting to include the link.
Logan Shaw
> WRT this thread:
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6c6fe13d14bf0d5a
> The ignorance in that thread is abundant indeed. For instance, read the
> following post:
>
>
> "Pops" does not check error return values and mutates data-structures
> under read-locks...
>
> I argued with him for a while... Sorry about that.
If you were really sorry, why did you post 19 more messages just in
the last few hours and after posting your apology? Your apology does
not seem sincere.
> He is a clear idiot, and I still tried to make my point...
>
>
> I apologize for cast my pearls before swine.
There's no need to apologize for casting your pearls before swine.
They're your pearls, if indeed they are pearls in the first place,
and not anyone else's concern, really. In fact, the only reason I
can imagine you may have posted that part of the "apology" is to
gain sympathy. You're apparently trying to drag other people into
the discussion and convince them to take your side by making a play
for the moral high ground with a token apology, despite the fact
that you obviously have no intention to change the behavior you
claim to be sorry about.
- Logan
Chris Thomasson
news:4737ab48$0$32564$4c36...@roadrunner.com...
> Chris Thomasson wrote:
>> WRT this thread:
>
>> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/6c6fe13d14bf0d5a
>
>> The ignorance in that thread is abundant indeed. For instance, read the
>> following post:
>>
>>
>> "Pops" does not check error return values and mutates data-structures
>> under read-locks...
>>
>> I argued with him for a while... Sorry about that.
>
> If you were really sorry, why did you post 19 more messages just in
> the last few hours and after posting your apology? Your apology does
> not seem sincere.
>
>> He is a clear idiot, and I still tried to make my point...
>>
>>
>> I apologize for cast my pearls before swine.
>
> There's no need to apologize for casting your pearls before swine.
> They're your pearls, if indeed they are pearls in the first place,
The pearls in this case were regarding the bugs I found in some code. I was
trying to being them to the attention of the author. I have failed.
> and not anyone else's concern, really. In fact, the only reason I
> can imagine you may have posted that part of the "apology" is to
> gain sympathy. You're apparently trying to drag other people into
> the discussion and convince them to take your side by making a play
> for the moral high ground with a token apology, despite the fact
> that you obviously have no intention to change the behavior you
> claim to be sorry about.
I have given up on that thread. I have failed to get my point across. I
can't do any more.
Hector Santos
wrote to Chris Thomasson wrote:
> There's no need to apologize for casting your pearls before swine.
> They're your pearls, if indeed they are pearls in the first place,
> and not anyone else's concern, really. In fact, the only reason I
> can imagine you may have posted that part of the "apology" is to
> gain sympathy. You're apparently trying to drag other people into
> the discussion and convince them to take your side by making a play
> for the moral high ground with a token apology, despite the fact
> that you obviously have no intention to change the behavior you
> claim to be sorry about.
The sad fact is that he continues to flood the Microsoft newsgroup
with this rthetoric. The kid is a troll. Smart, but its time to grow
up Chris. You don't have a copyright or patent on software
engineering issues.
--
Hector Santos, CTO
Santronics Software, Inc
http://www.santronics.com
Chris Thomasson
news:1194936864.3...@22g2000hsm.googlegroups.com...
Why don't you want to fix the problems I found with your code?
Hector Santos
> "Hector Santos" <sant9...@gmail.com> wrote in message
As it was explained numerous times by myself and others, they were
not deemed as problems by atleast 6 engineers with atleast 100+ more
of man-years experience. It is really bothering you that we refuse to
alter 12 years of high end production server code with billions of
365x24x7 working hours by hundreds of thousands of companies,
thousands responsible critical transactions, simply to add a return
value check on constructors not expected to fail and hasn't failed and
as it was explained numerous times, that for it to fail, the system
has to be completely unstable? That any issue would be completely
outside the whelm of the posted critsect.h? Or the reason issue here
is that this code challenged your own? which fails in its software
engineering to protect it entry points?
When are you going to get this a rest?
Chris Thomasson
> On Nov 13, 7:55 am, "Chris Thomasson" <cris...@comcast.net> wrote:
>> "Hector Santos" <sant9...@gmail.com> wrote in message
>>
>> news:1194936864.3...@22g2000hsm.googlegroups.com...
>>
>>
>>
>> > On Nov 11, 8:24 pm, Logan Shaw <lshaw-use...@austin.rr.com>
>> > wrote to Chris Thomasson wrote:
>>
>> >> There's no need to apologize for casting your pearls before swine.
>> >> They're your pearls, if indeed they are pearls in the first place,
>> >> and not anyone else's concern, really. In fact, the only reason I
>> >> can imagine you may have posted that part of the "apology" is to
>> >> gain sympathy. You're apparently trying to drag other people into
>> >> the discussion and convince them to take your side by making a play
>> >> for the moral high ground with a token apology, despite the fact
>> >> that you obviously have no intention to change the behavior you
>> >> claim to be sorry about.
>>
>> > The sad fact is that he continues to flood the Microsoft newsgroup
>> > with this rthetoric. The kid is a troll. Smart, but its time to grow
>> > up Chris. You don't have a copyright or patent on software
>> > engineering issues.
>>
>> Why don't you want to fix the problems I found with your code?
>
>
> When are you going to get this a rest?
The following constructor code of yours is bugged:
> inline TReaderWriter::TReaderWriter()
> {
> Readers = -1;
> ReadingOk = CreateEvent(NULL, TRUE, TRUE, NULL);
> ReadingActiveSemaphore = CreateSemaphore(NULL, 1, 1, NULL);
> WriterRecursion = 0;
> }
You code fails to check if CreateEvent/Semaphore actually succeeded. I don't
care what your 6 engineers say, they are obviously wrong.
Who agrees with me here?
Hector Santos
As it as explained to you for the UMPTHEEN time, for this to fail, I
presume you are thinking low memory, not only will the constructor
would fail upon instantiation, but the entire system would have to be
completely unstable which is a whole different engineering resolution
already under control.
Which part don't you understand?
Dave Butenhof
On any rational multiuser/multiprocess system, there is some form of
quota mechanism to prevent a user or application from oversubscribing
shared resources. I'm not a Windows programmer, and a google for
documentation of CreateSemaphore showed no useful information at all
(call GetLastError if it returns NULL, sure... but no indication at all
of WHY that might happen. Idiotic)... but, for example, on a UNIX system
or most any large enterprise system, you might hit the system or user
limit on semaphores, while everything else will be running just fine.
There may be reasons you think this doesn't apply to you. Assuming the
credentials of the application in question aren't fabricated (a
possibility I don't entirely discount), you may even be correct. Maybe
Windows doesn't have such quotas at all and simply lets you acquire
resources until either the process or system crashes -- in which case
clearly testing would be pointless. Or perhaps your application runs in
only a limited and carefully configured system where you know that only
it will consume semaphores, the system has at least <n> semaphores
available, and the application will never use more -- in which case
checking for that error would clearly be a waste of time.
Generally, though, the rule is that you should always check for errors
that may happen for reasons the application code cannot predict or
control. Process and thread quotas, or disk space, for example; or, for
MOST applications, semaphores, may be claimed asynchronously by any of a
number of different agents beyond the knowledge or control of a typical
application -- failing to check for such errors is generally just
irresponsible.
One exception is an application that has no persistent state. If it
doesn't finish cleanly, it has no external effect. No abandoned kernel
resources, temporary disk files, or anything else that a robust
application might ordinarily wish to clean up on an abnormal
termination. If you can't recover and continue, it may be easier
(possibly even "best") to just crash and let someone start over.
So, somehow, I guess you must be indirectly intending to argue that
these potential failures can be caused only by circumstances entirely
within your application's control; or that your application has no
persistent side effects and you (and your customers) are just willing to
accept that the occasional bizarre failure mode can be restarted.
In either case, though, you could probably respond with a bit more
reasoned rebuttal. And, Chris; you're basically repeating the same
taunt, and not even in particularly unique ways. We all get the message.
If you're not right, it's because of special circumstances that your
playground buddies haven't explained. But, really, so what? If their
application is busted in incredibly stupid ways and absolutely never
works correctly, why does it bother you? And if there are really reasons
that the operational restrictions are acceptable, or even appropriate,
for their environment, how is all this fuss helping anyone?
What I hear from you guys amounts to little more than school children
shouting back and forth on the playground "I'm rubber, you're glue;
whatever you say bounces off me and sticks to you." Amusing, perhaps,
the first 2 times through, for other school children. But really utterly
pointless. If you must rant and rave at each other, take it to private
email.
Please believe me, none of you are making any points posting this publicly.
Hector Santos
Thanks for your comments. Your generalizatons are well understood.
Some of your presumptions are incorrect, easiily to blurt out and
uncalled for, but primarily rest assured, I certainly do not need,
nor am I looking for any sympathy Believe me, I don't look to you or
anyone here for any moral ground or even technical.
But I do know cyberspace, being an early pioneer in the market, and
one thing I will not tolerate are torts, lies and insults. It will not
go unchallenged. Your friend insisted in bombarded and crossposting
insults, pitting one group against another and I am pretty confidence
if such a person did the same to you, you would not tolerate it as
well. Maybe you would. But who cares?
This all started with a friendly contribution in assisting an OP with
a typical synchronization design problem. Example code was posted to
outline a solution to explore. In comes Chris, who seems to proud of
his own RW work, took offense to our public cleaned up critsect.h
header with time tested critical section and self contained reader/
writer classes (no need to call lock/unlock). He had no contribution
to the original post topic and began to insult ALL developers who ever
attempted to write Reader/Writer synchronization code saying quote:
"they are all clueless..... This is is how you do it..." etc. Yet,
he admitted his work was all experimental. With no practical
engineering behind it, he simply didn't have the right to insult
people like this - in any forum. But go figure he continued to insult
me, my products and customers.
I gave him many outs, but he didn't take and continued on his quest to
prove useless points.
Unless unreasonble provoked, it is not in my nature to offend
anyone, but to teach him the proverbial "Pot calling the kettle
black", I pointed out his own software engineering problems with his
own code with are highly probable application lockups which do not
take any odd or rare external OS/HW influences to occur.
My advice to you is to ignore the thread. You're not teaching me
anything about engineering, insights or morals. If you choose to get
involves, well, that just tells me, you are just as corrupted or
cyberspace challenge as most are. It will die on its own. I will
say, if Chris is your friend, I would try to get him to stop cross
posting bullshit and stop insulting people.
Thanks again for your comments.
--
Hector Santos, CTO
Santronics Software, Inc
http://www.santronics.com
Chris Thomasson
news:fhcqbj$be1$1...@usenet01.boi.hp.com...
> Hector Santos wrote:
[...]
> In either case, though, you could probably respond with a bit more
> reasoned rebuttal. And, Chris; you're basically repeating the same taunt,
> and not even in particularly unique ways. We all get the message. If
> you're not right, it's because of special circumstances that your
> playground buddies haven't explained. But, really, so what? If their
> application is busted in incredibly stupid ways and absolutely never works
> correctly, why does it bother you?
It bothers me because a newbie might cut-and-paste the posted code and use
it, thinking that its perfectly okay, when its not. I needed to point this
out, and I got flamed by the author for doing so.
Simple Example:
Let's say that a person decides to use it in a scenario in which multiple
TReaderWriter objects would be protecting collections highly sensitive data
in a server. Lets say that the load on the server was such that one of those
TReaderWriter failed to create the event and semaphore object that your code
uses. Since your code fails to check for this condition the code will
continue merrily onward... Now, several threads whish to access the critical
data, and all run through all the failed calls to WaitForSingleObject. Oh
crap, one of those threads is a writer, and the others were all readers...
The writer mutates the data-structure as the readers read it and corrupts
their view of the data. Now the readers have read incoherent data and think
they everything is okay so the report the corrupted data back to the client
who ends up acting on it erroneously. This is a BAD scenario... Imagine if
the data had something to do with your bank account information?
> And if there are really reasons that the operational restrictions are
> acceptable, or even appropriate, for their environment, how is all this
> fuss helping anyone?
> What I hear from you guys amounts to little more than school children
> shouting back and forth on the playground "I'm rubber, you're glue;
> whatever you say bounces off me and sticks to you." Amusing, perhaps, the
> first 2 times through, for other school children. But really utterly
> pointless. If you must rant and rave at each other, take it to private
> email.
>
> Please believe me, none of you are making any points posting this
> publicly.
Well, I guess that if I helped somebody understand that the scenario
described above can happen if they use the posted code as-is, then I think
there was at least a shred of something good to come out of the sess pool?
Hector Santos
> "Dave Butenhof" <david.buten...@hp.com> wrote in message
> It bothers me because a newbie might cut-and-paste the posted code and use
> it, thinking that its perfectly okay, when its not. I needed to point this
> out, and I got flamed by the author for doing so.
You're worry about the newbie!? hahahahahaha, make this is really
fun. :-)
You should be more worry about the "newbie" using your library code
withi clear extremely high potential unprotected entry point
synchronization errors!
Example: This will lock up the application required a ^C/break abort:
void main(char argc, char *argv[])
{
rwmutex_win rw;
rw.rdunlock();
rw.rdunlock();
getch();
rw.rdlock();
}
Oh you could care less about the USER implementation of your code?
There are all kinds of more complex ways that this can happen. I only
had to show the SIMPLE one!!
But no, you are more worldly concern about a scenerio in our code
that is nearly impossible to happen and will take an act of god to
occur?
Sorry, I doubt the sincerity of that worry of yours. You just want to
tell the worry your CODE was better than any other developer conceived
Reader/Writer logic and quite frankly, I could care less if it was or
not (it turn out it wasn't). But don't insult people with this
nonsense of yours.
Chris Thomasson
> On Nov 13, 2:55 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
>> "Dave Butenhof" <david.buten...@hp.com> wrote in message
>
>> It bothers me because a newbie might cut-and-paste the posted code and
>> use
>> it, thinking that its perfectly okay, when its not. I needed to point
>> this
>> out, and I got flamed by the author for doing so.
>
> You're worry about the newbie!? hahahahahaha, make this is really
> fun. :-)
I am worried about a newbie blindly using your posted code as-is. Yes, that
happens to concern me quit a bit.
>
> You should be more worry about the "newbie" using your library code
> withi clear extremely high potential unprotected entry point
> synchronization errors!
>
> Example: This will lock up the application required a ^C/break abort:
>
> void main(char argc, char *argv[])
> {
^^^^^^^^^^^^^^^^^^^^^^^^^
void main is classic mistake. Anyway:
> rwmutex_win rw;
> rw.rdunlock();
^^^^^^^^^^^^^^^^^^^
What are you unlocking right here? You need to call rdlock before you call
rdunlock.
> rw.rdunlock();
> getch();
> rw.rdlock();
> }
I want to know why you tried to release read-access when you clearly did not
acquire it before? You example code is a direct analog of this:
int main(void) {
static pthread_rwlock_t rwlock=PTHREAD_RWLOCK_INITIALIZER;
pthread_rwlock_unlock(&rwlock);
pthread_rwlock_unlock(&rwlock);
getch();
pthread_rwlock_rdlock(&rwlock);
return 0;
}
Your unlock a read-lock when it has not already acquired one, that's clearly
wrong. Here is the corrected version of your example:
int main(char argc, char *argv[]) {
rwmutex_win rw;
rw.rdlock();
rw.rdlock();
getch();
rw.rdunlock();
rw.rdunlock();
return 0;
}
If you can see the mistake you made here, then, well, I don't know what else
to tell you. Perhaps David can convince you that unlocking a read-write
mutex when there was no prior acquisition is in error.
?
Hector Santos
> I am worried about a newbie blindly using your posted code as-is. Yes, that
> happens to concern me quit a bit.
Then I feel sorry for ya.
> I want to know why you tried to release read-access when you clearly did not
> acquire it before?
Because you made it possible to happen! Ask your friend Murphy.
> Your unlock a read-lock when it has not already acquired one, that's clearly
> wrong.
But since you allowed it to happen with HIGH probability, especially
in a real more complex multi-threaded application, I question who is
more wrong - the implementation, your library or both? Your library
certainly has problems and calling it "experimental" doesn't cut it.
By virtual of its own definitionn, "Experimental" means you run test
and you don't even test your own code's real error possibilities.
> If you can see the mistake you made here, then, well, I don't know what else
> to tell you.
You never did have anything of value to tell anyone.
> Perhaps David can convince you that unlocking a read-write
> mutex when there was no prior acquisition is in error.
Hahahahaa, right, David can convince me of this idiotic insanity you
are in!
Hold on, "let me get a chair." I'm all ears. This is better than
getting drunk!!
Dave Butenhof
>
> Thanks for your comments. Your generalizatons are well understood.
> Some of your presumptions are incorrect, easiily to blurt out and
> uncalled for, but primarily rest assured, I certainly do not need,
> nor am I looking for any sympathy Believe me, I don't look to you or
> anyone here for any moral ground or even technical.
OK, so WHY do you think my presumptions are incorrect? You see, that's
the whole point. You're very casual about deflecting any criticism,
direct or implied, by claiming it doesn't matter. You seem completely
unwilling to explain WHY, except to vacuously claim that you know all,
see all, and reveal nothing. I've been debugging threaded applications
for nearly 20 years, and I've seen quite a few "rock solid" commercial
attempts fall apart with small changes in environment because the rocks
were crumbly in the first place. Your product's history, even if true,
means absolutely nothing to me. Your attitude very definitely does.
Uncalled for? On the contrary -- by posting in a public forum you are
implicitly calling for public feedback on any aspect of your post.
That's life in the big city, sir.
The fact is that either your code is "peculiarly optimistic" about error
conditions or has special circumstances that aren't evident either in
the code or in your communications here. Clearly you're not going to
tell anyone; and while that's grounds for some suspicion it doesn't
prove anything. I really don't care whether circumstances guarantee your
code to work forever in its environment, whether it happens to have
worked so far by pure chance, or whether you're making the whole thing
up. I would however like to either turn this mud slinging into a
productive discussion or, if that's not possible, get it out of our way
so issues having to do with concurrent programming can get the attention
they deserve.
That last, I think, has to be mostly directed at Chris, whose posts on
this subject I think far outnumber both Pops and Hector combined. Which
is really just silly. You, on the other hand, haven't stopped posting
either. It'd be nice at least to see something new.
Chris Thomasson
> On Nov 13, 3:56 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
>
>> I am worried about a newbie blindly using your posted code as-is. Yes,
>> that
>> happens to concern me quit a bit.
>
> Then I feel sorry for ya.
>
>> I want to know why you tried to release read-access when you clearly did
>> not
>> acquire it before?
>
> Because you made it possible to happen! Ask your friend Murphy.
You purposely misused the class by releasing read-access when its was not
previously acquired.
You did:
{
rwmutex_win rw;
rw.rdunlock();
}
That is a fundamental error. I don't know how much more clearly I can put
it.
>> Your unlock a read-lock when it has not already acquired one, that's
>> clearly
>> wrong.
>
> But since you allowed it to happen with HIGH probability, especially
> in a real more complex multi-threaded application, I question who is
> more wrong - the implementation, your library or both? Your library
> certainly has problems and calling it "experimental" doesn't cut it.
> By virtual of its own definitionn, "Experimental" means you run test
> and you don't even test your own code's real error possibilities.
>
>> If you can see the mistake you made here, then, well, I don't know what
>> else
>> to tell you.
>
> You never did have anything of value to tell anyone.
[...]
Your tolling attempts are in vain. Did you use 'void main' on purpose to see
if you could goat me into personally attack you or something?
>> Perhaps David can convince you that unlocking a read-write
>> mutex when there was no prior acquisition is in error.
>Hahahahaa, right, David can convince me of this idiotic insanity you
>are in!
Well, its just that's is not right to unlock something that is not locked. I
don't know why you are arguing that things should work that way.
Dave Butenhof
> "Dave Butenhof" <david.b...@hp.com> wrote in message
> news:fhcqbj$be1$1...@usenet01.boi.hp.com...
>> Hector Santos wrote:
> [...]
>> If their application is busted in incredibly stupid ways and
>> absolutely never works correctly, why does it bother you?
>
> It bothers me because a newbie might cut-and-paste the posted code and
> use it, thinking that its perfectly okay, when its not. I needed to
> point this out, and I got flamed by the author for doing so.
Nice thought, but you're way past the point where that's going to help.
NO NEWBIE is going to be able to wade through the mess you guys have
left behind you, much less figure out who's right or why. There's too
much irrelevant chaff that can't be filtered without substantial
sophistication and experience.
>> Please believe me, none of you are making any points posting this
>> publicly.
>
> Well, I guess that if I helped somebody understand that the scenario
> described above can happen if they use the posted code as-is, then I
> think there was at least a shred of something good to come out of the
> sess pool?
He made a point. You made a counter-point. If you'd both left it at
that, people could read them both, try to judge the merits, and follow
up with specific questions to appropriate people -- here, at their work
or school, or whatever.
The trail is now so twisted and choked with debris that it's not a trail
anymore. Nobody who needs your advice is going to have the fortitude to
navigate this battlefield filtering for value. The cause is lost because
you chased it into a war zone. Now you can only let it die in peace. (I
started with a smiley here... but really, aside from the metaphor, I
mean it.)
Hector Santos
> Hector Santos wrote:
>
> > Thanks for your comments. Your generalizatons are well understood.
> > Some of your presumptions are incorrect, easiily to blurt out and
> > uncalled for, but primarily rest assured, I certainly do not need,
> > nor am I looking for any sympathy Believe me, I don't look to you or
> > anyone here for any moral ground or even technical.
>
> OK, so WHY do you think my presumptions are incorrect? You see, that's
> the whole point.
Exactly my point. Anyone can blurt anything as you continued to do in
this worthless message. And obviously you complaining about this, yet
you wish to be right in the middle too.
I've seen it all before David. Nothing new here, and I have no
interest to debate anything with you, nor challenge anything about you
nor question it, so you have no reason to challenge me. I mean that
just as much as this smile. :-)
--
HLS
Dave Butenhof
Thank you for removing all doubt. I'd been laboring under the impression
that under the right conditions you might be interested in saying
something related to software or programming methodology. Clearly I was
mistaken.
Good bye.
Chris Thomasson
> On Nov 13, 4:27 pm, Dave Butenhof <david.buten...@hp.com> wrote:
>> Hector Santos wrote:
>>
>> > Thanks for your comments. Your generalizatons are well understood.
>> > Some of your presumptions are incorrect, easiily to blurt out and
>> > uncalled for, but primarily rest assured, I certainly do not need,
>> > nor am I looking for any sympathy Believe me, I don't look to you or
>> > anyone here for any moral ground or even technical.
>>
>> OK, so WHY do you think my presumptions are incorrect? You see, that's
>> the whole point.
>
> Exactly my point. Anyone can blurt anything as you continued to do in
> this worthless message. And obviously you complaining about this, yet
> you wish to be right in the middle too.
I would take Davids message to heart.
>
> I've seen it all before David. Nothing new here, and I have no
> interest to debate anything with you, nor challenge anything about you
> nor question it, so you have no reason to challenge me. I mean that
> just as much as this smile. :-)
I want to apologize to you for all the personal attacks I made. I called you
an idoi%, and some other nasty names. Not cool. I was reverting back to
SenderX. Sorry about that non-sense. Anyway:
I just wanted to know why to continue to try and get a rise out of somebody?
David gave you good advise in that there might be some exceptional scenarios
in which a constructor fails to acquire an operating system synchronization
object simply because of an environment modification, or during unexpected
periods of load on the system.
Chris Thomasson
> Chris Thomasson wrote:
>> "Dave Butenhof" <david.b...@hp.com> wrote in message
>> news:fhcqbj$be1$1...@usenet01.boi.hp.com...
>>> Hector Santos wrote:
>> [...]
>
>>> If their application is busted in incredibly stupid ways and absolutely
>>> never works correctly, why does it bother you?
>>
>> It bothers me because a newbie might cut-and-paste the posted code and
>> use it, thinking that its perfectly okay, when its not. I needed to point
>> this out, and I got flamed by the author for doing so.
>
> Nice thought, but you're way past the point where that's going to help. NO
> NEWBIE is going to be able to wade through the mess you guys have left
> behind you, much less figure out who's right or why. There's too much
> irrelevant chaff that can't be filtered without substantial sophistication
> and experience.
Good point.
>>> Please believe me, none of you are making any points posting this
>>> publicly.
I am trying real hard to change my tone wrt any further responses to Hector.
>> Well, I guess that if I helped somebody understand that the scenario
>> described above can happen if they use the posted code as-is, then I
>> think there was at least a shred of something good to come out of the
>> sess pool?
>
> He made a point. You made a counter-point. If you'd both left it at that,
> people could read them both, try to judge the merits, and follow up with
> specific questions to appropriate people -- here, at their work or school,
> or whatever.
I pressed the issue way to hard.
> The trail is now so twisted and choked with debris that it's not a trail
> anymore. Nobody who needs your advice is going to have the fortitude to
> navigate this battlefield filtering for value. The cause is lost because
> you chased it into a war zone. Now you can only let it die in peace. (I
> started with a smiley here... but really, aside from the metaphor, I mean
> it.)
Yeah, we destroyed that perfectly good thread up. Indeed.
;^(...
Chris Thomasson
news:473d7f7a$0$4365$9b4e...@newsspool4.arcor-online.net...
> Hector Santos schrieb:
>
>> As it as explained to you for the UMPTHEEN time, for this to fail,
>> tor would fail upon instantiation, but the entire system would have
>> to be completely unstable which is a whole different engineering
>> resolution already under control.
>
> he won't learn because he as a strong mental disorder!
I am crazzzzzzzzzyyyyyy!
Chris Thomasson
> Chris Thomasson schrieb:
>
>>>> As it as explained to you for the UMPTHEEN time, for this to fail,
>>>> I presume you are thinking low memory, not only will the construc-
>>>> tor would fail upon instantiation, but the entire system would have
>>>> to be completely unstable which is a whole different engineering
>>>> resolution already under control.
>
>>> Forget our panjandrum Chis;
>>> he won't learn because he as a strong mental disorder!
>
>> I am crazzzzzzzzzyyyyyy!
>
Wwwwwwweeeeeeeeeeeee!