Re: BUG #16200: returned data from ESQL/C FETCH is trampling outside assigned memory for CHAR column

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

In response to

Responses

Browse pgsql-bugs by date

  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