corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Checking malloc success and adding perror()
Date Thu, 19 Feb 2015 00:33:29 GMT
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:jani@apache.org] 
Sent: Wednesday, February 18, 2015 14:00
To: dev@corinthia.incubator.apache.org
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 <gabriela.gibson@gmail.com>
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/
>


Mime
View raw message