Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Siddhesh Poyarekar]

On 07/04/2022 07:22, Siddhesh Poyarekar wrote:
> > 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.

FWIW, I've started a discussion on fortification strictness on the glibc 
mailing list[1].  However ISTM that it may well be simpler to just 
allocate MB_CUR_MAX all the time in unget_wch; it's likely you're 
getting a large enough block from malloc anyway so it's not like the 
precise length is saving any space.

Siddhesh

[1] https://sourceware.org/pipermail/libc-alpha/2022-April/137626.html