Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Siddhesh Poyarekar]

On 09/04/2022 20:37, Thomas Dickey wrote:
> I think the description is clear enough (if you disagree, the

I've been unable to convince anyone of my reading so obviously I've 
misinterpreted it.

> I misread that - wcrtomb shouldn't produce a trailing null,
> and need not use that detail from wcsrtombs :-)
>
> > >          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
>
> I see this, apparently applying to wcrtomb:
>
> https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_6.html
>
>         One word about the interface of the function: there is no parameter
>         specifying the length of the array s.  Instead the function assumes
>         that there are at least MB_CUR_MAX bytes available since this is the
>         maximum length of any byte sequence representing a single character.
>         So the caller has to make sure that there is enough space available,
>         otherwise buffer overruns can occur.
>
> so it's "documented" -- not in the manual page, but in the info document

Ahh, thanks for looking that up, I had missed it.  The info doc is the 
official glibc documentation...

> (but since I don't see the same limitation in other implementations, am
> unconvinced that it complies with POSIX).  By the way, the manual page
> mentions POSIX, while that section of the info document does not:
>
>         CONFORMING TO
>                POSIX.1-2001, POSIX.1-2008, C99.
>
> That paragraph in the info document doesn't allow for the case we're
> discussing:  where the application determines (using the POSIX interface) the
> number of bytes required, and uses that for the output buffer length.
> If glibc writes past that number, it's no longer an implementation "quirk", but
> a bug -- in glibc -- because it is not telling the application a correct number
> for the required bytes.

... so if it's documented in the manual then it's essentially a glibc 
extension that's evidently incompatible with POSIX.  That then explains 
the original rationale for implementing (back in 2007) the fortify check 
the way it has been.

> So far, all I've seen is an issue with a limit-check which doesn't
> agree with the expected value -- in glibc.  If the limit-check is
> wrong (and glibc works as expected _without_ that check), then it's
> a problem with the limit-check.

Not quite; the glibc implementation actually does assume internally that 
the end of the buffer is at MB_CUR_MAX, as it claims in its 
documentation.  Depending on the iconv converter module, it may or may 
not overflow the bounds of the input buffer while writing to it.  It's 
just that without fortification there's no deliberate, preemptive abort.

We're discussing this here[1], I'll loop you into that conversation so 
that it's all in one place.

Siddhesh

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