bug-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undetected fatal errors from redirected print


From: arnold
Subject: Re: Undetected fatal errors from redirected print
Date: Thu, 02 Dec 2021 06:48:42 -0700
User-agent: Heirloom mailx 12.5 7/5/10

"Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:

> On Thu, Dec 02, 2021 at 12:44:14AM -0700, arnold@skeeve.com wrote:
> > "Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:
> > 
> > > By the way, the logic in io.c:non_fatal_flush_std_file is somewhat 
> > > similar to
> > > builtin.c:wrerror. Maybe those should be somehow combined.
> > 
> > They are similar, but it looked a little too messy to combine them.
>
> Fair enough.
>
> > > Actually, the call to w32_maybe_set_errno() appears in 6
> > > places (main.c:usage, main.c:copyleft, builtin.c:wrerror,
> > > io.c:non_fatal_flush_std_file, io.c:close_io). Maybe there should be
> > > some attempt to unify this logic.
> > 
> > I have prettified this somewhat.  Git is updated.
>
> I see you didn't like the "return <function returning void>" construct. It's a
> bit weird, but I wrote a test program to prove it works as expected. Having
> changed efflush to get rid of that construct, wouldn't you need to patch
> efwrite as well (which is more painful, and the reason I did it that
> way in the first place)? It just seemed clunky to say { wrerror(); return; }
>
> Regards,
> Andy

Ah, I didn't notice that efwrite needs it too.

I have a memory that some compilers don't like

        return void_function()

even from a function that returns void.  I also think it's kind of
a weird thing to do.

I will try to fix efwrite.

Thanks,

Arnold



reply via email to

[Prev in Thread] Current Thread [Next in Thread]