Re: [HACKERS] Possible pointer dereference

2015-05-28 Thread Gaetano Mendola
While at it the assert(cnfa != NULL cnfa-nstates != 0); at src/backend/regex/rege_dfa.c:282 is issued too late indeed at line 278 and 279 cnfa was already dereferenced. Same for assert(t != NULL) in src/backend/regex/regexec.c:821 is issued way too late. On Thu, 28 May 2015 at 15:59 Tom

Re: [HACKERS] Possible pointer dereference

2015-05-28 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, May 27, 2015 at 8:57 PM, Haribabu Kommi kommi.harib...@gmail.com wrote: By correcting the following way will solve the problem. return ts ? (*ts != 0) : false; instead of retun *ts != 0; Attached a patch for it. If the only caller always

[HACKERS] Possible pointer dereference

2015-05-27 Thread Gaetano Mendola
I'm playing with a static analyzer and it's giving out some real error analyzing postgresql code base like the following one src/backend/access/transam/commit_ts.c return *ts != 0 // line 321 but a few line up (line 315) ts is checked for null, so either is not needed to check for null or *ts

Re: [HACKERS] Possible pointer dereference

2015-05-27 Thread Haribabu Kommi
On Thu, May 28, 2015 at 6:07 AM, Gaetano Mendola mend...@gmail.com wrote: I'm playing with a static analyzer and it's giving out some real error analyzing postgresql code base like the following one src/backend/access/transam/commit_ts.c return *ts != 0 // line 321 but a few line up