I think I found the reason.
One thing about this thread that may go unnoticed and
that the analysis is done in Windows compilation.
If we're talking about consistency, then the current implementation of pg_encoding_max_length is
completely inconsistent with the rest of the file's functions, even if it's to save a few cycles, this is bad practice.
int
pg_encoding_max_length(int encoding)
{
return (PG_VALID_ENCODING(encoding) ?
pg_wchar_table[encoding].maxmblen :
pg_wchar_table[PG_SQL_ASCII].maxmblen);
}
I think that something is wrong with that implementation,
because Coverity has many warnings about this.
Perhaps, this is a mistake, but I'm not convinced yet.
1. One #ifdef with a mistake, the correct is _WIN32 and not WIN32.
(src/common/encnames).
#ifndef WIN32
#define DEF_ENC2NAME(name, codepage) { #name, PG_##name }
#else
#define DEF_ENC2NAME(name, codepage) { #name, PG_##name, codepage }
#endif
Why does this ifdef exist?
If the correct is this?
#define DEF_ENC2NAME(name, codepage) { #name, PG_##name, codepage }
2. This path:
#define DEF_ENC2NAME(name, codepage) { #name, PG_##name }
DEF_ENC2NAME(EUC_JP, 20932),
What happens if pg_encoding_max_length is called
with Database->encoding equals 20932 ?
Can you test the v2 of the patch?
regards,
Ranier Vilela
