On 12.06.2019 16:47, William A Rowe Jr wrote: > On Tue, Jun 11, 2019 at 5:38 PM William A Rowe Jr <wr...@rowe-clan.net > <mailto:wr...@rowe-clan.net>> wrote: > > On Tue, Jun 11, 2019 at 1:44 PM Branko Čibej <br...@apache.org > <mailto:br...@apache.org>> wrote: > >> We either reserve about 2x buffers for file name >> transliteration in heap >> per thread, or we use the thread stack. As long as we trust >> that our utf-8 >> to ucs-2 logic is rock solid and the allocations and limits >> are correctly >> coded, this continues to be a safe approach. > > Apropos of that, for 2.0 we're about to or have already > ditched support for versions of Windows that do not have > native UTF-8/UTF-16 conversions (ah, yes ... Windows has > finally moved from UCS-2 to UTF-16). Wouldn't this be the > right time to switch to using Windows' functions instead of > staying with our own? Especially since, with the transition to > UTF-16, we have to deal correctly with surrogate pairs, > something our current code (IIRC) doesn't do. > > > A bit of a misnomer, the code is full of references to ucs-2 > w/surrogate pair > support, the combo of these is utf-16. The comments can be > refreshed to > today's utf-16 nomenclature. > > > How strongly do we feel about the naming? I have the following patch to > commit if we want to observe current convention in utf-naming and > deprecate > many (but not all) ucs references.
As far as I'm concerned, the naming (which is an internal matter, not part of the API) can stay as long as the implementation is correct. A comment to the tune of "it's actually UTF-16 but started life in the olden days when only UCS-2 existed" is good enough. -- Brane
