Re: Issue with unget_wch_sp and -D_FORTIFY_SOURCE

[Siddhesh Poyarekar]

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 :)

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 + 
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.

Thanks,
Siddhesh