Grokbase › Groups › PostgreSQL › pgsql-hackers › June 2007
FAQ
With today's CVS code (originally noticed with 8.2beta3), on a PC where
INT_MAX=0x7FFFFFFF=2147483647

postgres=# select version();
version
---------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 8.3devel on i386-unknown-netbsdelf4.99.20, compiled by GCC gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1 20070603)
(1 row)

postgres=# select to_char(2147483647,'999,999,999');
to_char
--------------
###,###,###
(1 row)

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
to_char
--------------
###,###,###
(1 row)

postgres=# select to_char(2147483648,'99,999,999');
to_char
-------------
##,###,###
(1 row)

postgres=# select to_char(2147483648,'9,999,999,999');
to_char
----------------
2,147,483,648
(1 row)

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)

postgres=# select to_char(1234567890123,'99,999,999,999');
to_char
-----------------
##,###,###,###
(1 row)

So strangely, to get the worrying WARNING, I seem to need >INT_MAX with
a format string with 1 less positions than necessary - no wonder I
seemed to only see it randomly...

Thoughts?

Cheers,

Patrick

Search Discussions

  • Alvaro Herrera at Jun 28, 2007 at 6:29 pm ⇧

    Patrick Welche wrote:
    With today's CVS code (originally noticed with 8.2beta3), on a PC where
    INT_MAX=0x7FFFFFFF=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
  • Tom Lane at Jun 28, 2007 at 7:09 pm ⇧

    Patrick Welche 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
  • Imad at Jun 28, 2007 at 7:53 pm ⇧
    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 wrote:
    Patrick Welche <[email protected]> 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
  • Tom Lane at Jun 29, 2007 at 12:25 am ⇧

    imad writes:
    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;
    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
  • Bruce Momjian at Jun 29, 2007 at 2:41 am ⇧

    Tom Lane wrote:
    Patrick Welche <[email protected]> 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.
    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. +

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 28, '07 at 6:16p
activeJun 29, '07 at 2:41a
posts6
users5
websitepostgresql.org...
irc#postgresql

5 users in discussion

Tom Lane: 2 posts Imad: 1 post Alvaro Herrera: 1 post Bruce Momjian: 1 post Patrick Welche: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase