| From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
|---|---|
| To: | rjuju123(at)gmail(dot)com |
| Cc: | ranier(dot)vf(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) |
| Date: | 2022-02-17 08:24:58 |
| Message-ID: | 20220217.172458.760758446159742763.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
At Thu, 17 Feb 2022 15:50:09 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in
> On Thu, Feb 17, 2022 at 03:51:26PM +0900, Kyotaro Horiguchi wrote:
> > So, the function doesn't return 63 for all registered names and wrong
> > names.
> >
> > So other possibilities I can think of are..
> > - Someone had broken pg_encname_tbl[]
> > - Cosmic ray hit, or ill memory cell.
> > - Coverity worked wrong way.
> >
> > Could you show the workload for the Coverity warning here?
>
> The 63 upthread was hypothetical right? pg_encoding_max_length() shouldn't be
I understand that Coverity complaind pg_verify_mbstr_len is fed with
encoding = 63 by length_in_encoding. I don't know what made Coverity
think so.
> called with user-dependent data (unlike pg_encoding_max_length_sql()), so I
> also don't see any value spending cycles in release builds. The error should
> only happen with bogus code, and assert builds are there to avoid that, or
> corrupted memory and in that case we can't make any promise.
Well, It's more or less what I wanted to say. Thanks.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daria Lepikhova | 2022-02-17 08:46:40 | Assert in pageinspect with NULL pages |
| Previous Message | Kyotaro Horiguchi | 2022-02-17 08:14:05 | Re: [Proposal] Add foreign-server health checks infrastructure |