| Age | Commit message (Collapse) | Author |
|---|
|
Since y1 is usually smaller than y0, the sign of (x0 - x1) * (y1 - y0)
is usually the same as that of (x0 - x1). This isn't always the case,
though, especially if y is 2^Large * small.
Also, the result of umul should be trimmed, so that we can trust that
z0, z1 are trimmed in kmul. Otherwise, if their signs are different,
bigadd(z1, z0) may become confused about which has greater magnitude and
perform an incorrect subtraction. Since the result of kmul comes from
bigadd(), which trims already, we need only trim the result of smallmul
to ensure that umul's result is trimmed.
|
|
|
|
So I can write
std.put("{w=?}{w=?}\n", field_a, max_width, field_b, max_width)
|
|
This allows formatting functions to pass off the valist to type-specific
formatters, which may themselves consume elements from the valist, and
still check for correct argument counts without passing around counter
variables.
|
|
|
|
|
|
Also, recalculate 2*R + M+ during the Fixup loop. This prevents rare
digit miscalculations: e.g.
std.put("{e,s=4}\n", std.flt32frombits(0x2899fbf7))
|
|
|
|
This prepares for intfmt being used within fltfmt for the exponent in
scientific notation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Only relevant change between 6.3 and 6.4 is adding unveil:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/syscalls.master.diff?r1=1.188&r2=1.180&f=h
|
|
The __getcwd syscall returning the length of the string was apparently
unintended and was changed in 6.5 -current to return 0 on success:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/vfs_getcwd.c#rev1.33
This causes std.getcwd to return an empty string, which at least breaks
`mbld test`.
This patch works with both the old and new behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move the nfmt > nvarargs check to where it can detect the imminent bad
access.
|
|
Since the exp() we use is sometimes wrong by 1 ulp, the final
multiplication has a possibility of increasing that to 2 ulps. Using fma
instead makes such a thing much less likely.
This makes some of our off-by-0s off-by-1s, and vice versa, but on the
whole it is a definite improvement.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instead of performing the arbitrary-precision calculation, we can
instead generalize [Tan90] slightly to use multiple levels of tables.
This isn't quite as wasteful.
|
|
|
|
|
|
|
|
This still doesn't make the function fast, but it's less embarassingly
slow now.
|
|
|
|
|
|
|
|
|
|
The singular piece of test data is the tuple that caused me to spend far
too long realizing that fast2sum is not always appropriate.
|
|
This makes accurately computing pown and powr easier.
|
|
Fast2sum is only for when magnitudes of the arguments are known. 2sum
(called "slow2sum") avoids this, at the cost of speed. It ends up being
necessary in the forthcoming log-overkill function.
|
|
|
|
|
|
|
|
Hi,
When using bio.readto I often want to be able to tell if the delimeter
was found, or if the file was truncated, but there doesn't appear to
be a way to tell if readto stopped searching because it found what it
was looking for or if it reached EOF, other than to do another read.
A simple solution to this would be a new function that reads to and
includes the delimeter in the returned slice if it was found, which can
be used intead when you care. I've tentatively included a patch for this.
Is this something that would be wanted? Is there a better solution? Or a
better name?
--
Carlin
NB. I've stolen the `Keep tag that was already there but apparently
never used. Not sure if it was intended for a higher purpose.
>From c230b380fbf0e7ba2c24aae332e4ce8016843d66 Mon Sep 17 00:00:00 2001
From: Carlin Bingham <cb@viennan.net>
Date: Sat, 16 Mar 2019 10:20:23 +1300
Subject: [PATCH] Add bio.readtoinc - read to including delimiter
X-Spam-Status: No, hits=0.000000 required=0.900000
Similar to bio.readto except it includes the delimeter in the returned
slice if it was found, making the absence of the delimiter indicate EOF
|
|
Unfortunately, this is necessary to achieve sequential consistency.
|
