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: | Raw Message | Whole Thread | 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 |