On 11/4/20 7:16 AM, Thomas Schwinge wrote:
>> I suspect that the bug is the "len" argument on the previous line
>> n = wcsrtombs(pathname, (const wchar_t **)&wpathname, len, &ps);
>>
>> Here "len" is byte length obtained for the original string from
>> strlen(). But the call seems to expect the length of the wide character
>> version in wpathname which was obtained above with xdupmbstowcs(), and
>> so the code should use the return value of that function (in variable
>> n) instead of len. Using too long a length makes wcsrtombs() set the
>> pointer to NULL when it continues to a zero character.
>
> So this is different from the change that Chet (CCed) applied to upstream
> bash-5.1-rc2, 'lib/glob/glob.c':
> <https://git.savannah.gnu.org/cgit/bash.git/diff/lib/glob/glob.c?h=bash-5.1-rc2>
> (via <https://bugs.debian.org/972286>).
>
> I cannot comment on the details, as I'm not at all familiar with these
> string APIs. Chet?
The prototype for wcsrtombs is (simplified):
size_t wcsrtombs(char *dst, wchar_t **src, size_t len, mbstate_t *ps)
In the prototype, LEN is the maximum number of bytes to store in DST.
In bash, since LEN is set from the number of bytes in the original
pathname, and the possibly-modified multibyte character pathname cannot
contain more than that number of bytes, LEN is appropriate.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
