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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
