At Thu, 17 Feb 2022 15:50:09 +0800, Julien Rouhaud <rjuju123@gmail.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
