View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009369 | GNUnet | ARM service | public | 2024-12-04 18:48 | 2024-12-09 18:03 |
| Reporter | oec | Assigned To | schanzen | ||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.23.0 | Fixed in Version | 0.23.0 | ||
| Summary | 0009369: parsing STEFAN_LIN fails under de_DE.UTF-8 locale | ||||
| Description | `make check` failed under exchange/src/testing because it couldn't start the exchange, due to the following error: ERROR Assertion failed at taler-exchange-httpd.c:2292. That is simply parsing the `STEFAN_LIN = 0.0` entry in the `[exchange]` section of the config. Turns out, under my locale setting (LANG=de_DE.UTF-8) the sscanf-format string "%f%1s", used for parsing that entry, fails because in German "." is a decimal separator for thousand. | ||||
| Steps To Reproduce | In exchange: src/testing try: > LANG=C taler-exchange-httpd -c test_exchange_api-rsa.conf and compare to > LANG=de_DE.UTF-8 taler-exchange-httpd -c test_exchange_api-rsa.conf (assuming you have that locale installed) | ||||
| Tags | No tags attached. | ||||
|
|
Nice find, but what's the *correct* canonical solution here? I'm not exactly sure... - resetting the local temporarily to C (ugly) - hacking the '.' into a ',' (not much better) - writing your own floating point parser (worse, brittle, horrible) - ???? |
|
|
It doesn't make sense at all that the outcome of parsing a config file depends on the locale setting of the user at runtime. I propose to: 1. add a config parameter "LANG" to the Taler configuration, with default value "C" 2. have a call to setlocale(LC_ALL, param) with this parameter at start of any taler program 3. document that parsing of (at least) floating point variables will depend on that LANG setting |
|
|
Oec's suggestion sounds quite reasonable, modulo that it probably needs or should to be done in GNUnet and not Taler. For the section name, I think "[environment]" or "[locale]" would IMO both be OK. Martin: do you agree? |
|
|
I agree with the C LANG default and that it is set. But I do not agree that it should be set for the whole program. First, it can be set only for the numeric values (I think). Second I think it can be controlled even tighter: You could use uselocale specifically for the config parser I guess and set it to "C". You could even to that only for the float parsing, but I strongly believe that a configuration file should be copyable between locales and still work. Yes, this could be done through the LANG, but the needlessly compicates things. The values themselves should be copyable. So just stick with uselocale. Other frameworks/languages where it is easier to parse float represent the float how? |
|
|
ACK, uselocale would do the job (and on single threaded programs be equivalent to setlocale, IIUC). Do you suggest that the float encoding should be bound to a fixed format? So, instead of [locale] LANG = de_DE@UTF-8 [some section] SOME_FLOAT = 1,0 ..., we would require that SOME_FLOAT is instead written as "1.0", essentially forcing it to be in C locale? |
|
|
Yes. Enforcing. I just pushed 2dbc55882..d095ae856 which should fix the issue. No need for an extra section. Config files should not be locale sensitive and for strings(!) that are, the application has to take care of that. |
|
|
2dbc55882..d095ae856 |
|
|
Released |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-12-04 18:48 | oec | New Issue | |
| 2024-12-04 18:48 | oec | Status | new => assigned |
| 2024-12-04 18:48 | oec | Assigned To | => Christian Grothoff |
| 2024-12-04 22:47 | Christian Grothoff | Note Added: 0023787 | |
| 2024-12-05 10:02 | oec | Note Added: 0023796 | |
| 2024-12-05 10:07 | oec | Description Updated | |
| 2024-12-05 12:10 | oec | Target Version | git (master) => 0.14 |
| 2024-12-06 09:07 | Christian Grothoff | Note Added: 0023801 | |
| 2024-12-06 09:07 | Christian Grothoff | Project | Taler => GNUnet |
| 2024-12-06 09:07 | Christian Grothoff | Category | exchange => General |
| 2024-12-06 09:07 | Christian Grothoff | Assigned To | Christian Grothoff => schanzen |
| 2024-12-06 09:07 | Christian Grothoff | Status | assigned => feedback |
| 2024-12-09 12:08 | schanzen | Note Added: 0023813 | |
| 2024-12-09 12:09 | schanzen | Note Edited: 0023813 | |
| 2024-12-09 12:09 | schanzen | Note Edited: 0023813 | |
| 2024-12-09 12:19 | oec | Note Added: 0023814 | |
| 2024-12-09 12:19 | oec | Status | feedback => assigned |
| 2024-12-09 12:41 | schanzen | Status | assigned => confirmed |
| 2024-12-09 12:41 | schanzen | Category | General => ARM service |
| 2024-12-09 12:41 | schanzen | Product Version | git (master) => |
| 2024-12-09 12:41 | schanzen | Target Version | 0.14 => 0.23.0 |
| 2024-12-09 13:30 | schanzen | Note Added: 0023816 | |
| 2024-12-09 13:31 | schanzen | Status | confirmed => resolved |
| 2024-12-09 13:31 | schanzen | Resolution | open => fixed |
| 2024-12-09 13:31 | schanzen | Note Added: 0023817 | |
| 2024-12-09 18:03 | schanzen | Fixed in Version | => 0.23.0 |
| 2024-12-09 18:03 | schanzen | Note Added: 0023837 | |
| 2024-12-09 18:03 | schanzen | Status | resolved => closed |
