Anders Johansson wrote:
On Sunday 23 December 2007 01:26:08 Carlos E. R. wrote:
The Saturday 2007-12-22 at 18:09 +0100, Anders Johansson wrote:
Actually, it helps solve it, sometimes. The application crashes,
probably
I wouldn't say "probably". It shouldn't be par for the course for an
application to not check return values from memory allocation functions
That's not what I said. Look again:
] The application crashes, probably
] with an error, maybe a core dump or a backtrace, and it can be examined.
There is a comma after the "crashes".
I didn't say that it "probably crashes". I said that it will
crash, and then probably will produce an error message.
The idea is that an application that has a memory hole and uses a lot of
memory doesn't crash, but by running with an "ulimit" it will crash when
it hits the limit, ant then the error, coredump, or backtrace can be
examined.
Well, the idea might work, but I still say that you're too dogmatic. Even an
application that forgets to free() memory can still test the return code from
malloc() properly. It's not a given that it will crash. It might just exit
normally, without a core being produced]
If it doesn't check return values from malloc()
(or something which calls malloc()), it WILL crash
due to a segmentation fault (trying to write to
structure members through a structure-pointer
which is NULL or -1.
If it does check return it can still crash, but
that would be due to other problems.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
