Zsh Mailing List Archive
Messages sorted by:
questions - calling matheval() for printf
- X-seq: zsh-workers 16022
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: questions - calling matheval() for printf
- Date: Fri, 12 Oct 2001 15:03:45 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- Sender: extok1
I have a few questions related to the use of matheval() for numeric
arguments to printf. According to the POSIX definition (which you can
read at http://www.opengroup.org/onlinepubs/007908799/xcu/printf.html),
with the %d format specification, and assuming 32-bit ints, the
following are the expect results:
argument stdout stderr
5a 5 printf: "5a" not completely converted
9999999999 2147483647 printf: "9999999999" arithmetic overflow
-9999999999 -2147483648 printf: "-9999999999" arithmetic overflow
ABC 0 printf: "ABC" expected numeric value
In the first case, the different error message doesn't worry me but
math evaluation doesn't return `5'. It is conceivable that someone
relies on this in a script, passing a string starting with a number and
redirecting stderr. I could successively chop characters off the right
of the string until matheval returns without an error. This would need
a hack to avoid repeated error messages from matheval(). Any other,
perhaps better suggestions?
Is there any way I can find out when arithmetic overflows have occurred
for the second and third cases? matheval() just allows the numbers to
In the last case, we'll just have to be non-compliant (it returns $ABC)
but that doesn't worry me much.
What is going on with this errval and zerr/zwarn stuff? I don't
entirely understand which I should be calling on errors and whether I
am right to zero errval after calling matheval() and reading it?
Can a 64-bit integer be something other than long long? It seems I only
have ZSH_64_BIT_TYPE to check and it might need a different format
specifier for printf(3) if this is something other than long long.
Aside from this, using matheval() works very smoothly and it is
certainly better that we won't lose precision due to converting floats
via ASCII before formatting..
Messages sorted by: