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

Previous Next

Full log

Message #71 received at 44320 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: larsi <at> gnus.org, sunlin7 <at> yahoo.com, 44320 <at> debbugs.gnu.org, lin.sun <at> zoom.us
Subject: Re: bug#44320: [PATH] [27.1] Make sure send-string-to-terminal send
 all contents
Date: Mon, 02 Nov 2020 21:31:14 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: lin.sun <at> zoom.us,  larsi <at> gnus.org,  sunlin7 <at> yahoo.com,
>   44320 <at> 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)?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.