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
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
