From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] pgcrypto: Test for NULL before dereferencing pointer |
Date: | 2010-10-20 20:36:39 |
Message-ID: | 3861.1287606999@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marti Raudsepp <marti(at)juffo(dot)org> writes:
> There's a file descriptor leak in psql/command.c function
> process_file() -- on errors it just returns without closing the file.
> But since it's quitting anyway, there's no practical impact. Should I
> submit a patch for this as well?
Might as well. It's the kind of thing that could turn into a real
bug given some rearrangement of the code.
> Then there's the 'badzero' check that finds a dozen cases where
> pointers are compared to a literal 0, not a NULL. This is a only a
> coding style check, as far as I can tell, so I thought it's not worth
> it.
I'd be in favor of fixing those too. I have no particular problem with
either "if (ptr)" or "if (ptr != NULL)", but I think that "if (ptr != 0)"
gives the reader entirely the wrong impression about the datatype of ptr.
Just because C fails to distinguish doesn't make it good style.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen R. van den Berg | 2010-10-20 21:30:50 | Re: pg_rawdump |
Previous Message | Greg Stark | 2010-10-20 20:33:41 | Re: max_wal_senders must die |