[Bug python/18207] New: _initialize_python () may fail to restore initial locale in gdb configured with Python 3

[Bug python/18207] New: _initialize_python () may fail to restore initial locale in gdb configured with Python 3

[ilmalakhov at yandex dot ru]

https://sourceware.org/bugzilla/show_bug.cgi?id=18207

            Bug ID: 18207
           Summary: _initialize_python () may fail to restore initial
                    locale in gdb configured with Python 3
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: ilmalakhov at yandex dot ru

Hi.

 Currently there is a bug in _initialize_python () in recent gdb versions
(including the one in master branch of binutils-gdb.git) configured with Python
3, which may show itself up when manipulating locales:

$ cat gdb/python/python.c
. . .
void
_initialize_python (void)
{
. . .
#ifdef IS_PY3K
  oldloc = setlocale (LC_ALL, NULL);
  setlocale (LC_ALL, "");
. . .
  setlocale (LC_ALL, oldloc);
. . .


 If the second setlocale () were to succeed, it might very well spoil the
string OLDLOC pointed to after the first one, because of which the third
setlocale () might fail. An obvious fix would be to strdup (OLDLOC) after the
first call to setlocale and free () it in the end, of course.

 From a user's point of view this bug can make it impossible to enter
floating-point numbers within gdb in a usual way, if his environment prevents
'.' from being interpreted as a decimal point:

$ LC_ALL=ru_RU.KOI8-R gdb
. . .
(gdb) p 1.5
Invalid number "1.5".
. . .

-- 
You are receiving this mail because:
You are on the CC list for the bug.