Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)
От | Julien Rouhaud |
---|---|
Тема | Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) |
Дата | |
Msg-id | 20220217084803.2pfygwh76r2xbx4g@jrouhaud обсуждение исходный текст |
Ответ на | Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c) (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
On Thu, Feb 17, 2022 at 05:24:58PM +0900, Kyotaro Horiguchi wrote: > 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. Not sure either. As you said this assumes that pg_char_to_encoding() can return something higher than _PG_LAST_ENCODING_ and I also fail to see how that could happen.
В списке pgsql-hackers по дате отправления: