> 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
be
> /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 pla
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
pri
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, b
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
pri
On Fri Mar 1 17:54:53 EST 2013, paul-a.patie...@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 pla
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 pla
On Mar 1, 2013, at 10:58, "Steve Simon" 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.
> 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
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
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.
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
#include
void
main(void)
{
print("%.5g\n", 12345.67890);
exits(nil);
}
term% 8.out
12345.7
In plan9port at least, it seems correct.
%.5g prints 12346 given 12345.67890.
Do you have an example it gets wrong?
-rob
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/
14 matches
Mail list logo
