Hi all,
currently `G_find_key_value` is case-sensitive (using strcmp). I
wonder if we could switch to `G_strcasecmp` (to be case-insensitive).
Or we need a new subroutine like `G_find_case_key_value()`?
Thanks for feedback, Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin Landa wrote:
currently `G_find_key_value` is case-sensitive (using strcmp). I
wonder if we could switch to `G_strcasecmp` (to be case-insensitive).
Or we need a new subroutine like `G_find_case_key_value()`?
Why does this matter?
The normal use case for those functions is to use a key which is
hard-coded into the source code with a file which was generated by
GRASS. In that situation, there shouldn't never be case mismatches.
Are there cases where those functions may be used with a file supplied
by the user which might have the wrong case?
Are there cases where those functions may be used with a key supplied
by the user which might have the wrong case?
Files which are generated by GRASS or which are part of GRASS should
always have the correct case, as should any keys supplied by GRASS.
One reason to ensure that the correct case is used is that it
eliminates potential issues when inter-operating with other languages.
Particularly languages which have a "dictionary" (associative array)
type, as such types normally treat the key as case-sensitive.
Most implementations of an associative array require that the
comparison is known in advance. Being able to choose case-sensitivity
at the point that a lookup is performed is only possible for a naive
implementation (such as GRASS') which iterates through a list of
key-value pairs. If you use a hashtable, btree, etc, you have to
decide whether to normalise the case at the point that an item is
inserted.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2012/3/21 Glynn Clements <glynn@gclements.plus.com>:
Why does this matter?
some files use upper-case for keys
cat ~/grassdata/nc_spm_08/pg/VAR
DB_DRIVER: sqlite
DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db
some lower-case
cat ~/grassdata/nc_spm_08/pg/GDAL
directory: /home/martin/smetiste/
format: GTiff
it would be probably better to consolidate naming convention to
upper-case. Then e.g. `r.external.out` would write GDAL file with
upper-case keys, in this case
DIRECTORY: /home/martin/smetiste/
FORMAT: GTiff
Case insensitive G_find_key_value() would enable eg. to read GDAL
files created before this change (lower -> upper).
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin Landa wrote:
> Why does this matter?
some files use upper-case for keys
cat ~/grassdata/nc_spm_08/pg/VAR
DB_DRIVER: sqlite
DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.dbsome lower-case
cat ~/grassdata/nc_spm_08/pg/GDAL
directory: /home/martin/smetiste/
format: GTiff
This isn't necessarily a problem.
it would be probably better to consolidate naming convention to
upper-case.
I would have said the opposite. Lower-case is more common, and easier
to read. $GISRC and VAR use upper-case; almost everything else uses
lower-case.
Then e.g. `r.external.out` would write GDAL file with
upper-case keys, in this caseDIRECTORY: /home/martin/smetiste/
FORMAT: GTiffCase insensitive G_find_key_value() would enable eg. to read GDAL
files created before this change (lower -> upper).
However, existing versions won't be able to read new files.
Also: are there any cases where the case actually matters? E.g. the
PROJ_INFO file use PROJ parameter names as its keys. Is that going to
cause problems if we change the case?
Any code which enumerates keys (e.g. pj_get_kv() in
lib/proj/get_proj.c) will need to be re-written to use
case-insensitive checks. And if there's any third-party code (e.g.
users' scripts) which parses key-value files directly (or uses the
output from programs which copy keys verbatim), it's going to be
broken by such a change.
--
Glynn Clements <glynn@gclements.plus.com>