Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Siddhesh Poyarekar]

On 07/04/2022 06:23, Thomas Dickey wrote:
> not quite:
>
>         the wcrtomb() function shall determine the number of bytes needed to
>         represent the character that corresponds to the wide character given by
>         wc (including any shift sequences), and store the resulting bytes in
>         the array whose first element is pointed to by s.  At most {MB_CUR_MAX}
>         bytes are stored.
>   
> That last part is a guarantee that the representation won't be longer
> than a given limit.  But writing zeroes out violates the first statement,
> if those bytes are not _needed_.

Does it though?  The first statement only says that those bytes are 
written out, not that _only_ those bytes (or needed bytes) are stored; 
the comment about the amoung of storage is only made in the second 
statement.

I'll admit however (in addition to the fact that I was the one who made 
that statement to Martin) that it's likely not the intended reading, 
which is why I qualified it with "defensive".  It's probably an 
unnecessary distraction since the stricter fortification decision in 
glibc is not based on that reading.

> However, the call that you're reporting on is a different problem than that.
>
> Offhand reading the code, it looks as if I didn't add 1 for the terminating
> null (in the call to malloc) which is documented here:
>
>         The wcsrtombs() function returns the number of bytes that make  up  the
>         converted  part  of  multibyte  sequence, not including the terminating
>         null byte.  If a wide character was encountered which could not be con‐
>         verted, (size_t) -1 is returned, and errno set to EILSEQ.

The glibc fortification (enabled by _FORTIFY_SOURCE) strictly requires 
the buffer to be MB_CUR_MAX long so despite fixing that bug (I trust 
your assertion on its existence) if the destination size is less than 
MB_CUR_MAX, the function will still crash.  Folks from the glibc 
community discussed this here[1] in the context of snprintf and comment 
1 in particular applies here; fortification checks may be stricter than 
what the standard requires.

Siddhesh

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28989