Re: [PATCHES] Problem with setlocale (found in libecpg) [accessing a

Поиск
Список
Период
Сортировка
Искать
От
Christof Petig
Тема
Re: [PATCHES] Problem with setlocale (found in libecpg) [accessing a
Дата
Msg-id
3BB2D494.3EF2381@petig-baender.de
Список
Дерево обсуждения
Re: [PATCHES] Problem with setlocale (found in libecpg) [accessing a Christof Petig <christof@petig-baender.de>
Re: [PATCHES] Problem with setlocale (found in libecpg) [accessing a Karel Zak <zakkr@zf.jcu.cz>
Tom Lane wrote:

> >> 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
> >> setlocale.
> >> So I would kindly ask you to take a second look at every invokation of
> >> setlocale.
>
> I looked around, and am worried about the behavior of PGLC_current()
> in src/backend/utils/adt/pg_locale.c.  It doesn't change locale but
> does retrieve several successive setlocale() results.  Does that work
> in glibc?

Well actually I did not check glibc's source code. But I tried to run my
program with efence and it aborted in execute.c

[   locale=setlocale(LC_NUMERIC,NULL);
    setlocale(LC_NUMERIC,"C");
     ...
    setlocale(LC_NUMERIC,locale);   // access to already freed memory
(locale)
]

So my best guess is that setlocale
- uses a malloced memory for return (which copes best with variable length
strings)
- frees this on a subsequent calls and allocates a new one.

Yes, I'm worried about PGLC_current(), too.
IMHO we should definitely copy the result to a malloced area.
Does the current solution work with static storage (old libcs?)? The last
call would overwrite the first result, wouldn't it?

Christof


В списке pgsql-hackers по дате отправления
От: Myron Scott
Дата:
От: Karel Zak
Дата:
Сообщение: Re: multibyte performance
FAQ