From: Dieter <Die...@ha...> - 2004-01-09 17:14:56
|
Am Donnerstag, 08. Januar 2004 00:41 schrieb Felix K=FChling: > Pavel, > > after reading your patch more carfully I decided to write the number > parsing functions myself. No offense, but your version does not parse > numbers in scientific notation like 1.5e-8, it is not good enough at > detecting errors in the input and in some cases it is even wrong. I > tested my functions in a separate programme quite thoroughly. If anyone > sees any further problems, please let me know. Thanks, fixed. But why I didn't got a copy for my topic? ;-) Greetings, Dieter > On Wed, 7 Jan 2004 16:41:38 +0100 (CET) > > Pavel harry_x Pal=E1t <ha...@ba...> wrote: > > > Looks like a problem with the new def_max_anisotropy option. It's the > > > first floating-point option. I don't understand why this is happening, > > > though. It works just fine in the radeon driver and the definitions of > > > __driConfigOptions are identical in both drivers (see r200_screen.c). > > > > > > Also, you should see the same problem with any OpenGL app. If this is > > > application-specific then it's really mysterious. > > > > > > Can you send the output of "xdriinfo options r200"? > > > > I have just experienced the same problem. The problem is that character > > which strtod recognise as decimal point depends on current locale. > > > > And in xmlconfig.c there is this part of code: > > case DRI_FLOAT: > > v->_float =3D strtod (string, (char **)&tail); > > break; > > And if the locale is set (which could be done by application or library > > like Xt), the parser will fail. > > > > Because of that I think that this code shouldn't depend on strtod(). The > > GNU extensions that allow to select locale in strtod call are > > non-standard. I think that best approach would be to have internal strt= od > > do the conversion. Here is small trivial patch that do it. =2D-=20 Dieter N=FCtzel @home: <Dieter.Nuetzel () hamburg ! de> |