On Sun, Oct 27, 2024 at 06:27:13PM +0100, Hiltjo Posthuma wrote:
> On Sun, Oct 27, 2024 at 03:05:37PM +0000, Raymond Cole wrote:
> > fputc() might set errno and thus affect perror().
> > ---
> > util.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/util.c b/util.c
> > index 96b82c9..a289160 100644
> > --- a/util.c
> > +++ b/util.c
> > _AT_@ -1,4 +1,5 @@
> > /* See LICENSE file for copyright and license details. */
> > +#include <errno.h>
> > #include <stdarg.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > _AT_@ -15,12 +16,9 @@ die(const char *fmt, ...)
> > vfprintf(stderr, fmt, ap);
> > va_end(ap);
> >
> > - if (fmt[0] && fmt[strlen(fmt)-1] == ':') {
> > - fputc(' ', stderr);
> > - perror(NULL);
> > - } else {
> > - fputc('\n', stderr);
> > - }
> > + if (fmt[0] && fmt[strlen(fmt)-1] == ':')
> > + fprintf(stderr, " %s", strerror(errno));
> > + fputc('\n', stderr);
> >
> > exit(1);
> > }
> > --
> > 2.46.2
> >
> >
>
> Thanks for the patch. I agree and the common pattern is even, at the top of
> the function:
>
> int saved_errno = errno;
>
> Then use (or restore) errno.
> I notice dmenu, dwm, libsl, sbase, etc have this bug.
What's the bugged output? Are there implementations that clobber errno
on success? Or are there circumstances where perror succeeds after fputc
has already failed?
>
> --
> Kind regards,
> Hiltjo
>
--
Storkman
Received on Sun Oct 27 2024 - 19:14:00 CET