On Thu, Jan 9, 2020, 20:21 Matthias Apitz <guru@unixarea.de> wrote:
Hello,
We encounter the following problem with ESQL/C: Imagine a table with two columns: CHAR(16) and DATE
The CHAR column can contain not only 16 bytes, but 16 Unicode chars, which are longer than 16 bytes if one or more of the chars is a UTF-8 multibyte encoded.
If one provides in C a host structure to FETCH the data as:
As you can see for the first item the length 17 is sent to the PG server together with the pointer to where the data should be stored and for the second element the length 11 is sent (which is big enough to receive in ASCII MM.DD.YYYY and a trailing \0).
What we now see using GDB is that for the first element all UTF-8 data is returned, lets asume only one multibyte char, which gives 17 bytes, not only 16, and the trailing NULL is already placed into the element for the date. Now the function ECPGdo() returns the date as MM.DD.YYYY into the area pointed to for the 2nd element and with this overwrites the NULL terminator of the string[17] element. Result is later a SIGSEGV because the expected string in string[17] is not NULL terminated anymore :-)
I would call it a bug, that ECPGdo() puts more than 17 bytes (16 bytes + NULL) as return into the place pointed to by the host var pointer when the column in the database has more (UTF-8) chars as will fit into 16+1 byte.
I would be cautious about naming this a bug as it is a classical buffer overflow (i.e. design) issue: if you have UTF-8 characters, your text is no longer 16-byte long and you should plan extra space in your variables.