https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847
--- Comment #22 from Janne Blomqvist <jb at gcc dot gnu.org> --- (In reply to Tobias Burnus from comment #21) > (In reply to Jerry DeLisle from comment #20) > > Created attachment 33858 [details] > > Proposed patch > > /* If the current locale is expecting a comma rather than a decimal > point, convert it now. */ > if (dtp->u.p.current_unit->decimal_locale == ',') > *strchr (buffer, '.') = ','; > > In principle, there are more options than just "," and "."; for instance, in > Britain, one often uses a centered dot (·) but that's not in the locale. > > Looking at the output of all my locales, I found: > ps_AF.utf8: 0٫400000 > as the only locale which doesn't use either a '.' or a ','. Interesting.. still, Jerry's patch looks like an improvement over the status quo and should cover the vast majority of cases. > Still, using a > code like the following looks more robust. > > /* During _gfortran_st_read/write. */ > const char *curr_locale = setlocale(LC_ALL, NULL); > setlocale(LC_ALL, "C"); > > ... > > /* During _gfortran_st_read_done/write_done. */ > setlocale(LC_ALL, curr_locale); I really don't think we should mess with setlocale(). It changes the process-wide locale, and if some other thread does something locale-dependent between our setlocale() calls there will be a bug in the user program which will be very hard to track down. As an aside, Jerry's patch suffers from similar issues, as the locale might be changed between checking the decimal separator (on OPEN) and using some locale-dependent functions. The robust solution really is to use strtod_l etc. as previously mentioned.
