Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: nandrews(at)investsystems(dot)co(dot)uk, justin(at)postgresql(dot)org, chriskl(at)familyhealth(dot)com(dot)au, vev(at)michvhf(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow
Date: 2002-08-21 01:10:09
Message-ID: 20020821.101009.35794276.t-ishii@sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > test=# \df iso8859_1_to_utf8
> > List of functions
> > Result data type | Schema | Name | Argument data types
> > ------------------+------------+-------------------+---------------------------------
> > integer | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer
>
> Right, that's what they are now, but what do the "-" entries really
> mean? Also, are the "integer" args and result truthful, or do they
> really mean something else?

They are like:

* conv_proc(
* INTEGER, -- source encoding id
* INTEGER, -- destination encoding id
* OPAQUE, -- source string (null terminated C string)
* OPAQUE, -- destination string (null terminated C string)
* INTEGER -- source string length

For the second and third argument they are actually treated as:

unsigned char *src = PG_GETARG_CSTRING(2);
unsigned char *dest = PG_GETARG_CSTRING(3);

The first one is an input parameter(source string), and second one is
an output parameter(destination string). The caller of this function
is responsible for allocationg enough memory for destination string.

The returned integer is actually dummy. The function always returns 1.
--
Tatsuo Ishii

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-08-21 01:18:46 Re: backpatch of datetime fixes
Previous Message Tatsuo Ishii 2002-08-21 01:09:26 Re: Large file support available