aboutsummaryrefslogtreecommitdiff
path: root/src/backend/jit/llvm/llvmjit_expr.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-11-03 13:56:10 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2018-11-03 13:56:10 -0400
commitbf4a9562e8b93ebb69715c7dbdfc90dd6945e369 (patch)
tree8603d594f64932e7838359c44f7064dd62849a78 /src/backend/jit/llvm/llvmjit_expr.c
parent33e6c34c32677a168bee4bc6c335aa8d73211a56 (diff)
downloadpostgresql-bf4a9562e8b93ebb69715c7dbdfc90dd6945e369.tar.gz
postgresql-bf4a9562e8b93ebb69715c7dbdfc90dd6945e369.zip
Make ts_locale.c's character-type functions cope with UTF-16.
On Windows, in UTF8 database encoding, what char2wchar() produces is UTF16 not UTF32, ie, characters above U+FFFF will be represented by surrogate pairs. t_isdigit() and siblings did not account for this and failed to provide a large enough result buffer. That in turn led to bogus "invalid multibyte character for locale" errors, because contrary to what you might think from char2wchar()'s documentation, its Windows code path doesn't cope sanely with buffer overflow. The solution for t_isdigit() and siblings is pretty clear: provide a 3-wchar_t result buffer not 2. char2wchar() also needs some work to provide more consistent, and more accurately documented, buffer overrun behavior. But that's a bigger job and it doesn't actually have any immediate payoff, so leave it for later. Per bug #15476 from Kenji Uno, who deserves credit for identifying the cause of the problem. Back-patch to all active branches. Discussion: https://postgr.es/m/15476-4314f480acf0f114@postgresql.org
Diffstat (limited to 'src/backend/jit/llvm/llvmjit_expr.c')
0 files changed, 0 insertions, 0 deletions