Re: Problem with setlocale (found in libecpg) [accessing a memory location after freeing it]

From: Michael Meskes <meskes(at)postgresql(dot)org>
To: Christof Petig <christof(at)petig-baender(dot)de>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Problem with setlocale (found in libecpg) [accessing a memory location after freeing it]
Date: 2001-09-25 18:15:06
Message-ID: 20010925201506.A1947@feivel.fam-meskes.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Mon, Sep 24, 2001 at 09:18:42AM +0200, Christof Petig wrote:
> well at first I could not believe what I was seeing ...

:-)

> Look at the following code (ecpg/lib/execute.c):
>
> const char *locale=setlocale(LC_NUMERIC, NULL);
> setlocale(LC_NUMERIC, "C");
> [....]
> setlocale(LC_NUMERIC, locale);
>
>
> Well at least on glibc-2.2 it seems that setlocale retuns a pointer to
> malloced memory, and frees this pointer on subsequent calls to

Doesn't look that way on my system. The following programs simply dumps core
in free().

#include <locale.h>
#include <stdio.h>

main()
{
const char *locale=setlocale(LC_NUMERIC, NULL);

printf("%c\n", locale);
free(locale);
}

> setlocale. This is standard conformant and has good reasons. But used as

You're partially right. Standard says "This string may be allocated in
static storage." So, yes, with your patch we are on the safe side. I just
committed the changes.

Michael

--
Michael Meskes
Michael(at)Fam-Meskes(dot)De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-09-25 18:56:59 O_DIRECT and performance
Previous Message Patrice Hédé 2001-09-25 18:14:20 Re: Unicode combining characters

Browse pgsql-patches by date

  From Date Subject
Next Message yasen 2001-09-26 08:29:24 troubles with setuid patch
Previous Message Kenneth Been 2001-09-25 18:12:30 rtree improvements