Re: [HACKERS] write past chunk end in ExprContext / to_char

2007-06-28 Thread Alvaro Herrera
Patrick Welche wrote:
 With today's CVS code (originally noticed with 8.2beta3), on a PC where
 INT_MAX=0x7FFF=2147483647
 
 postgres=# select to_char(1234567890123,'999,999,999,999');
 WARNING:  detected write past chunk end in ExprContext 0x845509c
 WARNING:  detected write past chunk end in ExprContext 0x845509c
  to_char  
 --
   ###,###,###,###
 (1 row)

Yes, it fails in 7.3, 7.4, 8.0, 8.1, 8.2 and HEAD.  Thanks for the
report.

-- 
Alvaro Herrera  http://www.amazon.com/gp/registry/5ZYLFMCVHXC
Executive Executive Summary: The [Windows] Vista Content Protection
 specification could very well constitute the longest suicide note in history.
  Peter Guttman, http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] write past chunk end in ExprContext / to_char

2007-06-28 Thread Tom Lane
Patrick Welche [EMAIL PROTECTED] writes:
 With today's CVS code (originally noticed with 8.2beta3), on a PC where
 INT_MAX=0x7FFF=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


Re: [HACKERS] write past chunk end in ExprContext / to_char

2007-06-28 Thread imad

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 [EMAIL PROTECTED] wrote:

Patrick Welche [EMAIL PROTECTED] writes:
 With today's CVS code (originally noticed with 8.2beta3), on a PC where
 INT_MAX=0x7FFF=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



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate


Re: [HACKERS] write past chunk end in ExprContext / to_char

2007-06-28 Thread Tom Lane
imad [EMAIL PROTECTED] writes:
 This is the problematic part in formatting.c, function dch_time.
 intsiz = 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;

Hmm.  That was not the buffer overrun I was looking at, but it sure
looks like another one :-(.  Thanks for spotting it!

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


Re: [HACKERS] write past chunk end in ExprContext / to_char

2007-06-28 Thread Bruce Momjian
Tom Lane wrote:
 Patrick Welche [EMAIL PROTECTED] writes:
  With today's CVS code (originally noticed with 8.2beta3), on a PC where
  INT_MAX=0x7FFF=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.

Agreed from personal experience.  I am in there wacking it around it
seems every release.

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate