bug#44320: [PATH] [27.1] Make sure send-string-to-terminal send all contents

[Eli Zaretskii <eliz@gnu.org>]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: lin.sun@zoom.us,  larsi@gnus.org,  sunlin7@yahoo.com,
>   44320@debbugs.gnu.org
> Date: Mon, 02 Nov 2020 19:58:17 +0100
> 
> On Nov 02 2020, Eli Zaretskii wrote:
> 
> > Is EINTR considered an error for this purpose?
> 
> Sure.

So if the call to 'write' made by 'fwrite' is interrupted by a signal,
and 'fwrite' didn't succeed to write anything, 'fwrite' will return
EOF and errno will be set to EINTR?  The proposed patch didn't handle
that case.

And if 'fwrite' was interrupted by a signal, but it succeeded to write
something, it will return a smaller count without setting errno?  Then
how to distinguish between a partial write due to a signal and a
partial write due to, say, disk full?

> > If not, what exactly is considered an error?  I don't see this clearly
> > documented, so it could be something we cannot rely on.
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fputc.html

Thanks.

> > In short, it sounds like calling fwrite in a loop will only work by
> > sheer luck.
> 
> I don't see why.

Too many subtle assumptions for my palate.  In general, stdio is not
safe in the presence of signals.

Would it be better to suspend SIGIO by calling unrequest_sigio instead
(and resume it once 'fwrite' returns)?