| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: Leakproofness of texteq()/textne() |
| Date: | 2019-09-12 16:44:55 |
| Message-ID: | CA+TgmoZdZAb1y9vN89cmW0TAKkOF=W2jK+rzv4AKm1BrhgwROw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 12, 2019 at 12:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After burrowing down further, it's visibly the case that
> text_cmp and varstr_cmp don't leak in the sense of actually
> reporting any part of their input strings. What they do do,
> in some code paths, is things like
>
> ereport(ERROR,
> (errmsg("could not convert string to UTF-16: error code %lu",
> GetLastError())));
Is this possible? I mean, I'm sure it could happen if the data's
corrupted, but we ought to have validated it on the way into the
database. But maybe this code path also gets used for non-Unicode
encodings?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-09-12 17:01:21 | Re: Leakproofness of texteq()/textne() |
| Previous Message | Tom Lane | 2019-09-12 16:19:04 | Re: Leakproofness of texteq()/textne() |