bug-gawk
[Top][All Lists]
Advanced

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

Re: [bug-gawk] inside awk script check that -M/--bignum given on command


From: Andrew J. Schorr
Subject: Re: [bug-gawk] inside awk script check that -M/--bignum given on command line?
Date: Fri, 5 Jan 2018 07:56:06 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Jannick,

On Fri, Jan 05, 2018 at 03:54:13AM +0100, Jannick wrote:
> 1 - 'exit 1' (as given in the BEGIN section of the example code you were
> quoting earlier from the gawk manual) is not an immediate exit, but it makes
> gawk jump to the END section which it then bravely works through and exits
> then (cf. 7.4.10 gawk manual, ed. 4.2). I know that this is really
> nitty-gritty, but I thought I mention that as a tiny contribution, since
> other users might wonder why a larger script with a huge END section does
> not immediately exit if the MPFR test fails.

This is a general AWK issue. Since this particular example doesn't include
an END section, I don't know how to address your concerns. In my own scripts,
I would probably do something like this if I had an END section:

BEGIN {
         if (! adequate_math_precision(fpbits)) {
             print("Error: insufficient computation precision available.\n" \
                   "Try again with the -M argument?") > "/dev/stderr"
             exit erc=1
         }
}

END {
        if (erc)
                exit erc
        ...
}

But I don't think it makes sense to add an END section to this snippet.
That seems to me more confusing than helpful.

What do you propose?

> 2 - The exact fpbits number in the example code is not really written in
> stone as such.

I'm not sure what you mean by written in stone. The idea is that any given
program may require a certain amount of precision to function correctly, so
the code should figure out what it needs and then ascertain whether gawk
is configured to provide sufficient accuracy. What are you driving at?

> While  the upper bound of fpbits depends on the machine the
> script is run on, it might well be OK to solve the problem with the lower
> precision (so my issue I got trapped in). 

I don't follow your line of reasoning here, so I don't know how to address your
concerns. What do you suggest?

Thanks,
Andy



reply via email to

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