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