Hi Tobias! >> The attached testcase requires gcc and gfortran, as well as a JDK >> installation. When running "make" with gcc/gfortran 4.7.2 and >> Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the >> behaviour of subsequent READ statements in the Fortran code, >> depending on the value of the LC_ALL environment variable. >> >> If this is a bug (it certainly feels like one to me), do you think >> it is fixable in either gcc or the Java libraries, or is this >> some unfortunate interaction that cannot really be fixed? >> If there is something that can be done in gcc, I'll be happy to open >> a full bug report. > > It sounds like the following bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007
Yes, I found that one too in the meantime :) > libgfortran calls libc's strtof/strtod/strtold/libquadmath's strtoflt128 > to convert the number. And that function is locale dependent - but > gfortran assumes that it uses a "." as decimal separator. > > It's surely fixable - the question is only what's the best approach. I > see the following possibilities: > > - Ignore the issue (not the best approach but the simplest. Also known > as: The compiler user has to handle it.) > - libgfortran should have its own parsing of the string. > - (Temporarily) reset the local setting before calling > strtof/strtod/strtold/libquadmath > - Convert the input to the used locale before calling > strtof/strtod/strtold/libquadmath > > I am in favour of the last option. The first one is the best current > solution for you (sorry!): Handle the locale issue it yourself. For me that's absolutely fine - now that I understand what happens. The problem is that for someone who has just noticed that their program behaves strangely it is _extremely_ hard to find the real reason. (In our case, it turned up after upgrading from JDK 1.6 to 1.7.) It would be very worthwhile to save other people this pain, so I would be glad if one of the other solutions could be be implemented. Maybe some code can be taken from libstdc++ ... things seem to work as expected there. Cheers, Martin
