[PATCH tabled] server/server.c don't deref NULL on failed malloc

[PATCH tabled] server/server.c don't deref NULL on failed malloc

[Jim Meyering]

Signed-off-by: Jim Meyering <meyering@redhat.com>
---
Just noticed that sometimes tabled uses this idiom:
  if (!(key = malloc(klen + 1)))
and sometimes this:
  if ((key = malloc(klen + 1)) == NULL)
This time I used "... == NULL".

 server/server.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/server/server.c b/server/server.c
index 2b4ef1c..3cec5ae 100644
--- a/server/server.c
+++ b/server/server.c
@@ -306,7 +306,8 @@ static char *pathtokey(const char *path)
 		return NULL;
 	klen = end - path;

-	key = malloc(klen + 1);
+	if ((key = malloc(klen + 1)) == NULL)
+		return NULL;
 	memcpy(key, path, klen);
 	key[klen] = 0;

--
1.7.3.234.g7bba3

Re: [PATCH tabled] server/server.c don't deref NULL on failed malloc

[Pete Zaitcev]

On Thu, 23 Sep 2010 13:03:15 +0200
Jim Meyering <jim@meyering.net> wrote:

> Just noticed that sometimes tabled uses this idiom:
>   if (!(key = malloc(klen + 1)))
> and sometimes this:
>   if ((key = malloc(klen + 1)) == NULL)
> This time I used "... == NULL".

Er... The bang is Jeff's, which I try to follow always, but perhaps
one or two slipped due to opposing habit. IIRC pathtokey() was mine.
In fact tabled does not use assignments in conditions, dunno why
but it's a tradition.

-- Pete

Re: [PATCH tabled] server/server.c don't deref NULL on failed malloc

[Jeff Garzik]

On 09/23/2010 10:07 AM, Pete Zaitcev wrote:
> On Thu, 23 Sep 2010 13:03:15 +0200
> Jim Meyering<jim@meyering.net>  wrote:
>
>> Just noticed that sometimes tabled uses this idiom:
>>    if (!(key = malloc(klen + 1)))
>> and sometimes this:
>>    if ((key = malloc(klen + 1)) == NULL)
>> This time I used "... == NULL".
>
> Er... The bang is Jeff's, which I try to follow always, but perhaps
> one or two slipped due to opposing habit. IIRC pathtokey() was mine.
> In fact tabled does not use assignments in conditions, dunno why
> but it's a tradition.

I always considered assignments in conditionals as fragile and 
error-prone, and try to avoid them.  However, I occasionally break my 
own rule, such as with fgets(3) or getopt(3) loops.

And, getting back on topic, I do prefer implicit rather than explicit 
testing for zero and non-zero...  but that too is a "weak preference" 
where I won't complain much if somebody else does it.

Typically the general rule for any codebase is "try to look like the 
rest of the codebase."

	Jeff