Closed metasim closed 8 months ago
One other thing that should be a separate issue, but it's too small: we might want a consuming into_ptr
method to prevent double-freeing in cases where GDAL takes ownership of the list. I think I saw this with WarpOptions
recently.
TL;DR:
The design of
CslStringList::iter
is incomplete, and arguably wrong altogether.Details
CslStringList
Is used extensively in GDAL to pass stringly represented arguments/parameters to a number of GDAL subsystems. It's a glorified wrapper around a C-array of C-strings (*mut *mut c_char
). The GDAL API provides a number of convenience methods for manipulating this memory in a slightly more safe way than working with the C pointers directly. The API has grown over time, and has some eccentricities about it that aren't obvious at first glance.One of these nuances is you can insert two forms of entries:
"KEY=VALUE"
CslStringList::set_name_value
CslStringList::fetch_name_value
"FLAG"
CslStringList::add_string
The current Rust binding design did not fully consider the flag form of entries, at least not from the read/fetch perspective (you can insert them, but never retrieve or view them).
Furthermore, the implementation of
CslStringList::iter
assumes the key-value form (returning(String, String)
, and skips over entries of the flag form, as illustrated by this test:As a consequence, Flag form entries are also excluded from
Debug
formatting, which makes it hard to inspect code having to useCslStringList
.Considerations
In addressing these inadequacies, the following decisions need to be made:
Iterator
returning both key-value and flag forms, or do we have two different iterators?Iterator
, what's the return type?CSLFindString
CSLFindStringCaseSensitive
CSLPartialFindString