If I might offer a small build on Jan's idea.
Define a function, null-check, perhaps an in-line one, that does something like
void* CheckAlloc(void* p)
{if (p == NULL)
AllocFailure();
return p;
}
with all other repetitive stuff in AllocFailure().
Invoke CheckAlloc with a malloc( ) call as its parameter, and put its result
wherever the non-null pointer is needed, casted as necessary.
You could even make a CheckedMalloc and even put the malloc call inside, passing
in the size_t. I am not certain how much that saves though.
Experiment?
- Dennis
-----Original Message-----
From: jan i [mailto:[email protected]]
Sent: Wednesday, February 18, 2015 14:00
To: [email protected]
Subject: Re: Checking malloc success and adding perror()
Hi
First thanks for your ideas, they are very welcome.
On 18 February 2015 at 22:19, Gabriela Gibson <[email protected]>
wrote:
> Hi,
>
> Reading through the source, I see that a lot of mallocs() do not have a
>
> [[
> if(foo == NULL) {
> perror("Foo: Out of memory.\n");
> return _exit(EXIT_FAILURE);
> }
> ]]
>
> check.
>
> I can add those if you like.
>
It get a big +1 from me.
BUT if you do it generally I would prefer we make a central function in
e.g. platform
void DFextBailout(<text>)
{
perror(...)
exit(EXIT_FAILURE)
}
That way we only need to change in one place if we e.g. one day want a
special logging.
I would NOT make a assert() like macro that includes the condition.
Please wait for Peter to comment, he might remember why there was no tests
in the first place.
rgds
jan i.
> G
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>
