[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