Re: gawk: sigpipe1.awk:7: fatal: print to "yes | true" failed: Broken pipe

[Andrew J. Schorr]

On Tue, Jan 02, 2024 at 03:39:06PM +0100, Manuel Collado wrote:
> El 2/1/24 a las 15:32, Andrew J. Schorr escribió:
> >
> >This seems odd to me. The code for the first one looks like this:
> >
> >    res = gettimeofday()
> >    st = systime()
> >    printf "gettimeofday - systime = %d\n", res-st
> >
> >The effect of "%d" should be to round down positive values and round up
> >negative ones. I'm jet-lagged so probably not thinking clearly, but I'm not
> >seeing how this can give a result of 1.  The awk gettimeofday() call should
> >simply map to the gettimeofday() system call, and systime() maps to time().
> >Do you understand how we're getting a result of 1? What type of system
> >is this? I'd find -1 more plausible on some insanely sluggish VM.
> 
> The cause may be a clock tick occurring between the first two statements.

There are definitely clock ticks between the 2 calls. Let's say that the
gettimeofday() call occurs at time t, and the subsequent systime() call occurs
at time t+eps. If I'm not mistaken, the time() system call used by systime()
should just truncate the time.  So what the gawk code is printing should be
this:

   truncate(t-truncate(t+eps))

If eps is large enough, this could result in a negative value, but how
can it be positive? To get a positive value, I think we need eps to somehow
have a negative value. If eps is non-negative, then shouldn't t-truncate(t+eps)
be less than 1? Maybe there's a weird floating-point rounding thing happening.
Suppose t = N+gamma, where N is an integer, and gamma is a fractional part that
approaches 1. Then truncate(t+eps) could also equal N, and t-truncate(t+eps)
would equal gamma. And then we'd have to suppose that gamma somehow gets
rounded up to 1 before the truncate. That seems unlikely to me. Or maybe
I'm delusional and missing something obvious.

Regards,
Andy