From: | Michael Meskes <meskes(at)postgresql(dot)org> |
---|---|
To: | guru(at)unixarea(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16200: returned data from ESQL/C FETCH is trampling outside assigned memory for CHAR column |
Date: | 2020-01-10 12:43:38 |
Message-ID: | c3b5c8c3375e5e4da53aae70b5152930dc3460e0.camel@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
> We encounter the following problem with ESQL/C: Imagine a table with
I assume you mean ECPG, right? ESQL/C would be the Informix compiler.
> In the database 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 an UTF-
> 8
> multibyte
> encoded char.
> ...
> the DATE. Now the function ECPGdo() places the DATE as "MM.DD.YYYY"
> into the area pointed to for the 2nd argument 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.
Actually I am not sure if this is a bug. I do not remember the standard
asking for a null termination at the end of a partial string copy.
Please correct me if I am wrong. What it does ask for is setting the
indicator accordingly. However, you do not mention any indicator, so I
wonder if you checked that one at all. If the string is truncated and
the appropriate error action is not taken, that would definitely
qualify as a bug.
Could you please verify if the indicator is set accordingly?
If you have a small test case to reproduce the issue, please send that
one. Otherwise I can create my own but probably won't have time before
next week.
Thanks
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-10 14:50:58 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
Previous Message | Mahendra Singh Thalor | 2020-01-10 12:24:21 | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |