------- Comment #5 from kargl at gcc dot gnu dot org 2008-07-19 20:23 ------- (In reply to comment #4) > Does setting the locale to POSIX in the above patch fix the issue if the > program using the runtime for example changes the locale just before calling a > Fortran routine that does some printing?
The patch sets locale to POSIX for both the gfortran frontend and the runtime library. POSIX defines the LC_NUMERIC decimal glyph to be a period. > Also, does the locale change affect other parts of the program calling the > gfortran runtime? If the other parts are written in Fortran, then no affect. In a mixed language environment see below. > If the program is threaded? If yes, just changing the locale > may cause some unexpected problems for the caller. Should have no effect on threaded apps. > > The reason I noticed this bug was that a user of the Scipy library (a > scientific library, for Python, that includes some routines written in > Fortran) > was experiencing a mysterious "printf is broken" error when writing a program > using the library. In this case at least, locale was probably changed after > libgfortran was loaded, and it would be unexpected if calling a Fortran > routine > changed the locale. > The Fortran standard is silent with respect to locale. The patch I propose has gfortran enforce POSIX locale. It is the programmers responsibility to handle it in a mixed language environment. The pseudocode is getlocale() /* Get current locale */ call_gfortran_routine() /* gfc enforces POSIX */ setlocale() /* Restore the locale from getlocale */ Of course, this is IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36857
