Let me start by saying I "don't have a dog in this fight."
However, as a follower of this mailing list, I do have an opinion about
the nature of conversations held here.
Mr. Walker's approach to this issue is not something I would recommend.
Regardless of the accuracy of the assessment, there's little to be
gained from criticizing the quality of work product, motives or judgment
of the product author. It's clear that Mr. Crispin and Mr. Walker have
a difference of opinion on this matter, and since it's Mr. Crispin's
project, I think his position trumps other opinions.
Mr. Walker, if you are so passionate about this matter, there are many
options available to you. The source code is available. You may
create a fork for your site, or perhaps select a different tool, or
write one from scratch. When engaged in future differences of opinion,
I'd like to suggest that you approach it without criticism of the
author's judgment. It's possible that Mr. Walker is 100% right about
the failure option. Frankly I have not considered the matter and have
not formed an opinion about the veracity or advisability of either
approach. However, after one has been criticized, one is frightfully
unwilling to reconsider - one must save face. You may attain a greater
level of success in taking a less personally confrontational tack in the
future. It's up to you.
Respectfully,
Tom Cooper
Shawn Walker wrote:
Mark Crispin wrote:
On Fri, 1 Dec 2006, Shawn Walker wrote:
Why for the life of me is I cannot understand your library calls
abort() to crash the application because of out of memory
No debugged application on any modern system should ever run out of
memory. Period. Even Microsoft agrees that 16-bit systems are dead
and the corpse is rotting. On non-toy computers, "out of memory" was
something that stopped happening sometime in the 1970s or 1980s.
That's laughable! We have QA run test on low to out of memory to test
that the applications does not crash or bring the system down because
of out of memory. It's GOOD practice to check for memory allocation
failure. If everybody were to follow your logic, there would be a
lot of bad applications causing unpredictable results.
If a malloc() call fails, the worst thing for the application to do
in such a case is to engage in untested (and likely ill-conceived)
recovery code that probably will make matters worse...including
obscuring the place where the fault occurred.
So in your theory that would mean *nix and windows kernels should call
panic just because the system ran out of memory? Yeah right.
There is a special place in hell for programmers who do things like
foo = malloc (bar);
if (foo == 0)
return;
Oh really? What is this in your code?
void *block = malloc (size ? size : (size_t) 1);
if (!block) fatal ("Out of memory");
You mean you didn't mean to check to see if the result from malloc is
not 0? If you don't care about the result from malloc, why are you
doing the check?
Not long ago, I wasted many hours tracking down a bug in a certain
program (name withheld to protect the guilty) that had a bit of code
very much like that above. It miscalculated bar (it was a negative
value), and never did the action which followed that snippet.
It's frustrating that happens because of other people bad code, but
that doesn't mean you should write bad code to panic just because
something failed.
or encounter an error from the server.
I have no idea what you are talking about here. The only abort()s in
c-client are internal consistency checks. Nothing that a server can
send will cause c-client to do an abort().
That's also bad practice, if something failed on the consistency
check, just return error of "invalid parameter" or "invalid data", etc
and let the application deal with the error of either not process
whatever it was doing and inform the user of the error.
That is a big no no, please change your library to return a failure
and have the application that is calling your library to deal with
errors.
Sorry, but that isn't going to happen. I am not going to revoke an
18 year old old guarantee that certain c-client functions never fail;
nor change the hundreds (if not thousands) of places which rely upon
that guarantee.
It's your refusal to grasps that you did write bad coding just to
abort the library. I care less how much trouble you have to go
through to fix your library to return a failure when something failed.
If the applications refuses to check for errors, then that is their
problem.
No, it's the problem of whomever has to deal with applications that
sweep problems under the rug.
Wow, so let's contact Linus Torvalds, Bill Gates and Steve Jobs that
they need to change the kernel to just panic when a driver or
application does something bad. Let's see how far your logic will fly.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
