diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-03-08 16:32:29 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-03-08 16:32:29 -0500 |
| commit | 6c20bdb2a279086777a3595ab00bcf14671fc5a1 (patch) | |
| tree | e3072396155102c9b7b8c8c30962dc5cc2f4d565 /src/backend/regex/rege_dfa.c | |
| parent | 8a812e5106c5db50039336288d376a188844e2cc (diff) | |
| download | postgresql-6c20bdb2a279086777a3595ab00bcf14671fc5a1.tar.gz postgresql-6c20bdb2a279086777a3595ab00bcf14671fc5a1.zip | |
Further tweak memory management for regex DFAs.
Coverity is still unhappy after commit 190c79884, and after looking
closer I think it might be onto something. The callers of newdfa()
typically drop out if v->err has been set nonzero, which newdfa()
is faithfully doing if it fails. However, what if v->err was already
nonzero before we entered newdfa()? Then newdfa() could succeed and
the caller would promptly leak its result.
I don't think this scenario can actually happen, but the predicate
"v->err is always zero when newdfa() is called" seems difficult to be
entirely sure of; there's a good deal of code that potentially could
get that wrong.
It seems better to adjust the callers to directly check for a null
result instead of relying on ISERR() tests. This is slightly cheaper
than the previous coding anyway.
Lacking evidence that there's any real bug, no back-patch.
Diffstat (limited to 'src/backend/regex/rege_dfa.c')
| -rw-r--r-- | src/backend/regex/rege_dfa.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/backend/regex/rege_dfa.c b/src/backend/regex/rege_dfa.c index 18f87c69d47..1d79d734468 100644 --- a/src/backend/regex/rege_dfa.c +++ b/src/backend/regex/rege_dfa.c @@ -604,6 +604,8 @@ lastcold(struct vars *v, /* * newdfa - set up a fresh DFA + * + * Returns NULL (and sets v->err) on failure. */ static struct dfa * newdfa(struct vars *v, |