[9fans] Bug in print(2) g verb

[Paul Patience]

I already sent this mail, but it seems that 9fans didn't
receive it.

The g verb in print(2) does not work properly. The precision
flag (%.ng) is supposed to print n significant figures, but
it prints n+1 significant figures. This change fixes this
behaviour.

diff -r d6b623d4cac0 sys/src/libc/fmt/fltfmt.c
--- a/sys/src/libc/fmt/fltfmt.c Sat Feb 23 14:05:51 2013 +0100
+++ b/sys/src/libc/fmt/fltfmt.c Wed Feb 27 15:59:34 2013 -0500
@@ -187,6 +187,8 @@
* c3 digits of trailing '0'
* c4 digits after '.'
*/
+ if(chr == 'g') /* Significant figures. */
+ prec--;
c1 = 0;
c2 = prec + 1;
c3 = 0;

[Rob Pike]

In plan9port at least, it seems correct.

%.5g prints 12346 given 12345.67890.

Do you have an example it gets wrong?

-rob

[Paul A. Patience]

Without the change, it should get
any example wrong. This is with
native Plan 9, though. Plan9port's
fltfmt.c is not the same, so it must
be working correctly.

term% cat foo.c
#include <u.h>
#include <libc.h>

void
main(void)
{
print("%.5g\n", 12345.67890);
exits(nil);
}
term% 8.out
12345.7

[Kurt H Maier]

Post by Rob Pike
In plan9port at least, it seems correct.

He wasn't asking about plan9port.

[Rob Pike]

But the code looks the same in plan9port at that point. So it looks
like a fix was made somewhere else in that file and not put back into
the Plan 9 sources. The proposed fix is perhaps not the best one.

-rob

[Steve Simon]

Post by Rob Pike
So it looks
like a fix was made somewhere else in that file and not put back into
the Plan 9 sources.

Just an idea, but now that gcc has kenc compatibility modes thanks to a GO author,
plan9ports could be merged back with mainline plan9 to a large extent.
It could then become a much smaller porting layer and a script which pulls
down much of /sys/src/cmd from plan9.

The idea is for both communities to take advantage of each others bug fixes
and enhancements.

This relies on gcc running everywhere p9p runs (which may or may not be true),
and somone with the time to do the work...

-Steve

[Anthony Sorace]

This relies on gcc running everywhere p9p runs...

s/gcc/sufficiently modern gcc/
I think that's the bigger issue. How far back in time is p9p looking to support platforms from? I have at least one box in the basement with a much older gcc on it. In my particular case, nothing prevents me from upgrading (except how painful dealing with gcc is), but I doubt that's true for everyone.

Relatedly, does anyone happen to know whether clang/llvm have these extensions as well?

[Paul A. Patience]

Plan9port's implementation of fltfmt.c seems
different enough to me that it isn't possible to
simply take the fix from there and add it to
plan9. Perhaps I'm missing something.

The g verb already acts differently in plan9port
and native plan 9: print("%g\n", 0.1) prints .1 in
plan 9 and 0.1 in plan9port. I don't why they're
different, but the former behaviour is unfortunate
for the native port of awk I am completing
(started by boyd).

Others are of course welcome to come up with fixes
for this problem.

[erik quanstrom]

Post by Paul A. Patience
Plan9port's implementation of fltfmt.c seems
different enough to me that it isn't possible to
simply take the fix from there and add it to
plan9. Perhaps I'm missing something.
The g verb already acts differently in plan9port
and native plan 9: print("%g\n", 0.1) prints .1 in
plan 9 and 0.1 in plan9port. I don't why they're
different, but the former behaviour is unfortunate
for the native port of awk I am completing
(started by boyd).
Others are of course welcome to come up with fixes
for this problem.

here are all the places where %g is used with a prec.
i think this should be trivial to fix. we just
need to agree to fix it. i would vote for fixing it.

- erik

---
chula; g '%([# +]|-)?([*0-9]+)?(\.[*0-9]+)g' /sys/src|grep -v printf|grep -v '/awk/|/gs/'
/sys/src/ape/lib/fmt/test.c:34: print("%2.18g\n", 1.0);
/sys/src/cmd/aux/msexceltables.c:286: Bprint(bo, "%-*.*g", min, max, c->number);
/sys/src/cmd/aux/vga/main.c:331: trace("refresh %.1g\n", rr);
/sys/src/cmd/aux/vga/main.c:333: fprint(2, "reducing %.1g to 85Hz\n", rr);
/sys/src/cmd/du.c:65: print("%.6g%s\t%q\n", val, pfxes[scale], name);
/sys/src/cmd/du.c:67: print("%.6g\t%q\n", (double)amt/unit, name);
/sys/src/cmd/hoc/code.c:586: print("%.12g\n", d.val);
/sys/src/cmd/hoc/code.c:595: print("%.12g ", d.val);
/sys/src/cmd/ip/gping.c:936: seprint(g->msg+n, e, " %3.3g", f/1000000);
/sys/src/cmd/nettest.c:143: print("%llud bytes in %g s @ %.2g MB/s (%ldms; limit %.2g MB/s)\n", i, delta, ratemb, sleepms, maxr);
/sys/src/cmd/nettest.c:146: print("%llud bytes in %g s @ %.2g MB/s (0ms)\n", i, delta, ratemb);
/sys/src/games/mp3enc/timestatus.c:153: "%9.4f" SPEED_CHAR "|" : "%#9.5g" SPEED_CHAR "|",
/sys/src/libmach/machdata.c:209: return snprint(buf, n, "%.18g", fr);
/sys/src/libmach/machdata.c:242: return snprint(buf, n, "%.9g", fr);
/sys/src/libstdio/dtoa.c:8: * printed as %.17g. Then atof(s) is exactly y.

[Richard Miller]

Post by erik quanstrom
/sys/src/cmd/hoc/code.c:586: print("%.12g\n", d.val);

Conceivably changing this could break somebody's rc script which depends on
hoc leaving out the leading zero. But unlikely (one hopes) that someone with
the taste to use Plan 9 would write anything so fragile...

I vote we converge with plan9port's behaviour on this.

[erik quanstrom]

Post by Richard Miller
Conceivably changing this could break somebody's rc script which depends on
hoc leaving out the leading zero. But unlikely (one hopes) that someone with
the taste to use Plan 9 would write anything so fragile...

looks like /rc/bin is safe, but ironicly, uptime(1) hacks around the current
behavior.

- erik

[a***@skeeve.com]

Changing the subject here...

Post by Paul A. Patience
....
for the native port of awk I am completing
(started by boyd).

I was under the impression that awk was a native port, but I could
be wrong.

In any case, I recommend that you start with BWK's latest, which is
availble on github:

git clone git://github.com/onetrueawk/awk

And also talk to Erik who did some work on bringing the Plan 9 awk into
sync with BWK's a little while back.

HTH,

Arnold

P.S. The git repo includes his test suite in the file awktest.a; it should
probably be unarchived in a separate directory from the source.

[Paul A. Patience]

I am actually the one who asked bwk for his test
suite, which he later put on github. I started
with some gawk tests while waiting for the test
suite, however.

As for plan9's awk, it runs on ape. I am trying
to make it run without ape. I had thought of
starting with the latest version of awk, but
boyd's port was nearly complete (it's in contrib).
All I've been doing is making small bugfixes here
and there. I'm not finished yet, but it won't be
too much longer, hopefully. Perhaps after that I
can take a look at the latest awk.

[erik quanstrom]

Post by Paul A. Patience
As for plan9's awk, it runs on ape. I am trying
to make it run without ape. I had thought of

don't. it's not worth it.

- erik

[Kurt H Maier]

Post by erik quanstrom

Post by Paul A. Patience
As for plan9's awk, it runs on ape. I am trying
to make it run without ape. I had thought of

don't. it's not worth it.
- erik

[citation needed]

[erik quanstrom]

Post by Kurt H Maier

Post by erik quanstrom

Post by Paul A. Patience
As for plan9's awk, it runs on ape. I am trying
to make it run without ape. I had thought of

don't. it's not worth it.
- erik

[citation needed]

uh, no. this is obvious.

awk is designed for a posix environment.
ape is the plan 9 posix environment. they'll
be happy together.

- erik

[Kurt H Maier]

Post by erik quanstrom
awk is designed for a posix environment.

bullshit. was ls also designed for a posix environment? awk is at
least ten years older than posix.

[erik quanstrom]

Post by Kurt H Maier

Post by erik quanstrom
awk is designed for a posix environment.

bullshit. was ls also designed for a posix environment? awk is at
least ten years older than posix.

should i say "the current ot awk source"? it's certainly not
designed for plan 9.

- erik

[Kurt H Maier]

Post by erik quanstrom

Post by Kurt H Maier

Post by erik quanstrom
awk is designed for a posix environment.

bullshit. was ls also designed for a posix environment? awk is at
least ten years older than posix.

should i say "the current ot awk source"? it's certainly not
designed for plan 9.
- erik

That wasn't the section of the message you quoted.

[Dan Cross]

Post by erik quanstrom
should i say "the current ot awk source"? it's certainly not
designed for plan 9.

Regardless you are right that it is clearly not worth porting to 'native'
Plan 9 libraries or APIs; what, if anything, would be the benefit of such
an effort?

- Dan C.

[Kurt H Maier]

Post by Dan Cross

Post by erik quanstrom
should i say "the current ot awk source"? it's certainly not
designed for plan 9.

Regardless you are right that it is clearly not worth porting to 'native'
Plan 9 libraries or APIs; what, if anything, would be the benefit of such
an effort?
- Dan C.

Not worth *what*? Someone else's time? The only reason we're talking
about a bug in print(2) is because of this waste-of-time native awk
work. This isn't some kind of zero-sum game where the opportunity cost
of someone making a native awk is depriving us of valuable other
software. Pretty much anything anyone writes for plan 9 is 'not worth
it' from an economical perspective; pretending Program A is worth less
than Program B is a little silly. In the meantime Paul has fun, finds
bugs to fix, and I'm one step closer to eradicating ape on my systems.
He doesn't answer to 9fans; stop trying to get him to justify himself to
you.

khm

[erik quanstrom]

Post by a***@skeeve.com
Changing the subject here...

Post by Paul A. Patience
....
for the native port of awk I am completing
(started by boyd).

I was under the impression that awk was a native port, but I could
be wrong.
In any case, I recommend that you start with BWK's latest, which is
git clone git://github.com/onetrueawk/awk
And also talk to Erik who did some work on bringing the Plan 9 awk into
sync with BWK's a little while back.

this is a long-finished project, which is included in 9atom.
i've been happy with the results. there haven't been any odd fpes
with venti scores or what have you.

i thought this had been submitted, but i guess not. if there is any
interest, i would be happy to submit it.

- erik

[Richard Miller]

Post by erik quanstrom

Post by a***@skeeve.com
And also talk to Erik who did some work on bringing the Plan 9 awk into
sync with BWK's a little while back.

...
if there is any
interest, i would be happy to submit it.

Here's one vote in favour.

[Paul A. Patience]

I would also like it if %g acted the same in plan9
as everywhere else (printing 0.1 instead of .1 in
my example). That's also really easy to change.

It doesn't make sense for plan9port's %g to be
different from plan9, because now you cannot even
count on both prints to work the same way. Since
printf's %g works like plan9port right now, it
would make sense to change plan9's version.

I don't know the history behind %g's current
behaviour, however.

[erik quanstrom]

Post by Paul A. Patience
I would also like it if %g acted the same in plan9
as everywhere else (printing 0.1 instead of .1 in
my example). That's also really easy to change.
It doesn't make sense for plan9port's %g to be
different from plan9, because now you cannot even
count on both prints to work the same way. Since
printf's %g works like plan9port right now, it
would make sense to change plan9's version.
I don't know the history behind %g's current
behaviour, however.

i don't have access to 3e sources, but 2e does not
add the extra digit like current plan 9 source does.
(it does however omit the leading 0 on 0.1.)

looking at the differences, i think there's a clue in
the 2e comments

/*
* n is number of digits to convert
* 1 before, f2 after, 1 extra for rounding
*/

we can see that after the label "found:" c1 is set
to prec+1, but that's including the rounding digit.
(cf. "try decimal rounding" above.)

it looks like a simple error in converting the code
from the old non-va_args style to the current style.

- erik

p.s. i haven't talked to anyone to wrote the code, so
maybe somebody who knows more about this than i
could chime in?

[Paul A. Patience]

I would also like it if %g acted the same in plan9
as everywhere else (printing 0.1 instead of .1 in
my example). That's also really easy to change.

It doesn't make sense for plan9port's %g to be
different from plan9, because now you cannot even
count on both prints to work the same way. Since
printf's %g works like plan9port right now, it
would make sense to change plan9's version.

I don't know the history behind %g's current
behaviour, however.

[erik quanstrom]

Post by erik quanstrom

Post by a***@skeeve.com
And also talk to Erik who did some work on bringing the Plan 9 awk into
sync with BWK's a little while back.

...
if there is any
interest, i would be happy to submit it.

Here's one vote in favour.

good enough!

/n/sources/patch/bwk-awk-update

- erik