Re: write past chunk end in ExprContext / to_char

This is the problematic part in formatting.c, function "dch_time".

int siz = strlen(tmtcTzn(tmtc));

if (arg == DCH_TZ)
strcpy(inout, tmtcTzn(tmtc));
else
{
char *p = palloc(siz);

strcpy(p, tmtcTzn(tmtc));
strcpy(inout, str_tolower(p));
pfree(p);
}
return siz;

here, doing a palloc with "siz+1" solves the issue but following /
making the convention, pstrdup should be used instead which is
specifically written for this purpose.

Probably too small a change for a patch ?

--Imad
www.EnterpriseDB.com

On 6/29/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> writes:
> > With today's CVS code (originally noticed with 8.2beta3), on a PC where
> > INT_MAX=0x7FFFFFFF=2147483647
>
> > postgres=# select to_char(2147483648,'999,999,999');
> > WARNING: detected write past chunk end in ExprContext 0x845509c
> > WARNING: detected write past chunk end in ExprContext 0x845509c
>
> Yech ... it's scribbling on the output of int8out, which is bad enough,
> but it's assuming that buffer will be long enough when it demonstrably
> isn't.
>
> Some days I think we ought to throw out formatting.c and rewrite it from
> scratch; it's probably the most poorly-coded module in all of Postgres.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>