[Top][All Lists]

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

Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]

From: Eli Zaretskii
Subject: Re: [bug-gawk] Behavior of fflush with SIGPIPE on stdout [PATCH]
Date: Sun, 26 Mar 2017 17:29:35 +0300

> Date: Sun, 26 Mar 2017 13:24:49 +0200
> From: FERRIEUX Alexandre - IMT/OLN <address@hidden>
> CC: <address@hidden>, <address@hidden>
> >>    #ifdef unix
> >>    # define SIGPIPE_EXIT_CODE (128|SIGPIPE)
> >>    #else
> >>    # define SIGPIPE_EXIT_CODE 1
> >>    #endif
> >
> > This isn't guaranteed to produce 141 on every system, so you don't get
> > what you want except a small number of platforms.
> Sure, I'll get what I need on a "small number" of platforms: only unix :)))

You mean, only one? ;-)

> > AFAIK, Gawk attempts to provide a more or less portable environment,
> > and the above is against that goal.
> On platforms where the exit status is only a bit, it returns 0 if OK, 1 if 
> not.

What platforms are those?  I'm not aware of any such platforms we

If you allude to MS-Windows, then the exit status there is a full
32-bit word, certainly not narrower than on a typical Unix.  To some
extent, it's richer than the Unix status, because it provides the
fatal exception which caused the program to exit abnormally, and
exceptions are more granular than Unix signals.

Does that mean we should model our exit status on Windows, because
it's richer?  Of course not!

> On platforms where the exit status is richer, it uses the richer bandwidth.
> In all cases the contract "0 if OK, !=0 if not" is enforced.

This isn't about the width of the exit status, this is about its
value, and about the importance (or lack thereof) of a particular
value produced when Gawk exited due to a certain errno.

> Is that against portability ?

The way you want it? yes, because I cannot write a portable Awk script
without system dependencies.

reply via email to

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