Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Thomas Dickey]

On Tue, Apr 12, 2022 at 10:19:52AM +0530, Siddhesh Poyarekar wrote:
> On 12/04/2022 05:34, Thomas Dickey wrote:
> > > 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.
> > 
> > sure - but it's a bug (I fix bugs that are older than that)
> 
> I don't disagree, I'm looking for additional historical context from the
> glibc community that I may have missed before I propose a change because
> that coded behaviour is after all deliberate.  I've been contributing there
> for about a decade, but that code precedes my involvement by at least
> another half decade :)

I recall seeing the comment about the limit before, but unless
one compiles with that fortify option, it doesn't interfere with
portability :-)
 
> FWIW though, it may well be more optimal for ncurses to simply provide a
> stack allocated VLA of MB_CUR_MAX than doing the size computation +

MB_CUR_MAX isn't necessarily a constant, and so far I've found no need
to make ncurses incompatible with c89.

> malloc+free dance.  It's an unrelated optimization since MB_CUR_MAX is
> unlikely to ever reach a point where stack allocations become harmful; the
> largest value in glibc-provided charmaps is 6 bytes (for UTF-8) at the
> moment.

Perhaps Ulrich had some other conversion in mind.
But neither the documentation or the code gives any hints.
(Possibly the misbehaving converters were fixed...)

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature