[RFC PATCH] Warn about commas in floating point values?

Dirk Hohndel dirk at hohndel.org
Thu Mar 7 13:26:26 PST 2013


Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Thu, Mar 7, 2013 at 12:25 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> Do you think this is something we should alert the user with a GError
>> about? Or should we just do this silently? I'm torn... my expectation
>> would be that this happens only on the rare occasions when people import
>> from odd formats - and in that case a GError might be a good idea to
>> encourage them to take a closer look at the data...
>
> If we simplify the xslt translations, we can't warn about it.

Umm, what? You lost me.

> At the same time, it would probably be nice for *developers* to see
> it. Probably just once, though, not for every value. So maybe that
> 'fprintf()' together with a static flag variable or something.

Yes - and that can stay an fprintf as I assume developers (even on
Windows) get to see stdout / stderr. Is that correct, Lubomir?

> Or we could do a GError, and just have a separate flag that silences
> it for non-native ones. So we'd only get the error if we see it from a
> native subsurface xml load.

My rationale for the GError would have been that this indicates a
potential issue with an import. Which is very different from the warning
just about a native Subsurface file (where this should NEVER occur).

I am guessing I am missing something here, so let's try to recap:

- if we detect a native file and a ',' instead of a '.' that gets a
  GError and an fprintf for good measure.
- once we remove the ,->. translations from XSLT we should now be able
  to warn the user of a potential issue with an import from different
  software - that should also be a GError (and no fprintf).

/D


More information about the subsurface mailing list