Cannot enter floating point (double) numbers

Bug #1341125 reported by Fabrizio Gennari
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdb
Unknown
Unknown
gdb (Ubuntu)
New
Low
Unassigned

Bug Description

(gdb) show version
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) p 1.0
Invalid number "1.0".

Yet, the latest git (tested 76bd66cfb5207137dac01534cf7d8af8f708743b from today) recognises 1.0 just fine, as a double

Revision history for this message
Fabrizio Gennari (fabrizio-ge) wrote :

After further investigation it seems that gdb assumes that floating-point numbers use . as decimal mark, as these lines from c-exp.y show

            else if (!got_dot && *p == '.')
              got_dot = 1;

but, later, the function parse_float() (in parse.c) feeds the string into sscanf

  num = sscanf (copy, "%" DOUBLEST_SCAN_FORMAT "%n", d, &n);

and, apparently, sscanf is locale-sensitive, so, if the current locale has , as decimal mark, sscanf will leave everything past the . sign unscanned. gdb, then, notices that something is unscanned and says "invalid number"

Revision history for this message
Fabrizio Gennari (fabrizio-ge) wrote :
Revision history for this message
Matthias Klose (doko) wrote :

this works for me in 14.10

Changed in gdb (Ubuntu):
importance: Undecided → Low
status: New → Triaged
status: Triaged → Fix Released
Revision history for this message
Fabrizio Gennari (fabrizio-ge) wrote :

Sorry, but I can still reproduce it.

Precondition is that gdb is built with Python 3 support (and the one distributed with Ubuntu 14.10 is) and the current locale has a comma as decimal separator (I am using it_IT.UTF-8).

At startup, gdb executes _initialize_python () (in file python/python.c): the following lines of code changhe the locale from C (which is the appropriate one, since gdb must be able to parse numbers that are valid in C language) to the one of the machine

1651 progname = concat (ldirname (python_libdir), SLASH_STRING, "bin",
1652 SLASH_STRING, "python", NULL);
1653 #ifdef IS_PY3K
1654 oldloc = setlocale (LC_ALL, NULL);
1655 setlocale (LC_ALL, "");

From this point on, gdb assumes that the decimal separator is a comma, and becomes unable to parse the number 1.0

Changed in gdb (Ubuntu):
status: Fix Released → New
Revision history for this message
Fabrizio Gennari (fabrizio-ge) wrote :

It works correctly if started as

LC_NUMERIC=C gdb

to force the correct locale

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.