Re: write past chunk end in ExprContext / to_char
От | imad |
---|---|
Тема | Re: write past chunk end in ExprContext / to_char |
Дата | |
Msg-id | 1f30b80c0706281253s77100405u8675f1b7f7fa236b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: write past chunk end in ExprContext / to_char (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: write past chunk end in ExprContext / to_char
|
Список | pgsql-hackers |
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@sss.pgh.pa.us> wrote: > Patrick Welche <prlw1@newn.cam.ac.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 >
В списке pgsql-hackers по дате отправления: