|
From: | Daniel J Sebald |
Subject: | Re: printf and locale |
Date: | Sat, 23 Feb 2013 14:35:13 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
On 02/23/2013 01:48 PM, Rik wrote:
2/23/13 All, There's a new bug report on the tracker where the locale of the user is causing gnuplot to choke (https://savannah.gnu.org/bugs/index.php?38372). The problem is on the development branch where printf has been patched to respond to locale and is now emitting lines like "linewidth 0,500000" instead of "linewidth 0.500000" which gnuplot expects. There is already a bug report about the locale patch causing an error in 'make check' if the fr_FR locale is not installed. I wonder if we haven't moved too quickly to add locale support without considering all of the necessary changes. It seems to me that we either need to seriously examine the code base for all possibe locale-aware constructs, or back off until we have enough time and manpower to tackle this project.
It's a tricky problem. To convert 0,50000 back to 0.50000 is difficult after the fact because it requires context; so that's not a good way to go. That means
1) At the point of translating the float machine representation into ASCII there needs to be a test of the locale flag and conditional tests on what the output destination is.
or2) Just before displaying to the screen a routine could scan the output line and convert and decimal points to commas.
#1 is bad in the sense that it runs against the paradigm of generating output which can be redirected. #2 is sort of clumsy or may not cover all basis (i.e., is the command line/pager output the only place where decimal-point should be translated to a comma-point?).
Dan
[Prev in Thread] | Current Thread | [Next in Thread] |