Re: [9fans] Bug in print(2) g verb
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
On Sun Mar 3 12:57:49 EST 2013, paul-a.patie...@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
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
/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
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
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
On Mar 1, 2013, at 10:58, Steve Simon st...@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?
[9fans] Bug in print(2) g verb
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;
