[gdal-dev] Using a "standard" argument parser for command line utilities?
Even Rouault
even.rouault at spatialys.com
Fri Mar 8 09:27:43 PST 2024
>
> In principle the idea sounds good.
>
> How is it parsing the numbers? is it locale agnostic? I think it is
> not, because it is using "strtod". That means that if I have my locale
> in Spanish, French, German, ... it will expect "," as the decimal
> separator, right?
if running under a non-C locale, and without modification, yes
> ... well, how is GDAL expecting floating values?
Only if the utilities enables setlocale(LC_ALL, ""), which they don't by
default. That said as the command line utility parsing is also used for
the utility-as-C-function, we may run under a non-C locale (that is a
Spanish/French/whatever locale) in some contexts.
> Is GDAL locale agnostic?
Grep'ping I see that we use both CPLAtof() which is locale-agnostic and
assume dot as decimal separator or CPLAtofM() which accept dot or comma
as decimal separator. I don't think there is a particular reason in
using any of them. Inconsistency likely due to doing the work manually
and depending on the mood of the developer. Not totally sure of the
behavior we want: should we always require dot as the decimal separator,
or be lenient and accept both dot and comma (wondering if there wouldn't
be situations where we would take a "a,b,c" string, with a, b, c being
floating point numbers, in which case obviously we would have to require
dot. But I'm not sure if that can happen)
>
> Do you want to add it as a dependency, or just copy-paste the header
> file into gdal repo?
yes, copy-paste and potentially with a few changes for our needs, like
using CPLAtof or CPLAtofM.
--
http://www.spatialys.com
My software is free, but my time generally not.
More information about the gdal-dev
mailing list