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

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

[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.

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

[erik quanstrom]

> 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

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

[Richard Miller]

> /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.

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

[erik quanstrom]

On Sun Mar  3 12:57:49 EST 2013, paul-a.patience@polymtl.ca wrote:
> 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?

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

[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.

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

[erik quanstrom]

On Fri Mar  1 17:54:53 EST 2013, paul-a.patience@polymtl.ca wrote:
> 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.

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

[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.

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

[Anthony Sorace]

On Mar 1, 2013, at 10:58, "Steve Simon" <steve@quintile.net> wrote:

> 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?

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

[Steve Simon]

> 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

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

[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

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

[Kurt H Maier]

On Thu, Feb 28, 2013 at 04:08:24PM -0800, Rob Pike wrote:
> In plan9port at least, it seems correct.

He wasn't asking about plan9port.

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

[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

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

[Rob Pike]

In plan9port at least, it seems correct.

%.5g prints 12346 given 12345.67890.

Do you have an example it gets wrong?

-rob

[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;