Per termios, read waits for MIN chars even if the number of requested
bytes is less. This requires to add WaitCommEvent to wait non-busily
for MIN chars prior to calling ReadFile, so, reintroduce it.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Sharing the OVERLAPPED struct and event object in there between
read and select calls in the fhandler might have been a nice
optimization way back when, but it is a dangerous, not thread-safe
approach. Fix this by creating per-fhandler, per-call OVERLAPPED
structs and event objects on demand.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- make sure event object is reset
- set read_ready to true if WaitCommEvent returns success
- improve debugging
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
tcsetattr checks if the VTIME and VMIN values changed and only
calls SetCommTimeouts if so. That's a problem if tcsetattr
is supposed to set VTIME and VIMN to 0, because these are the
start values anyway. But this requires to set ReadIntervalTimeout
to MAXDWORD, which just doesn't happen.
Fix this by dropping the over-optimization of checking the old
values before calling SetCommTimeouts,
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
After changing the type of fhandler_serial::vtime_ to cc_t, vtime_
must be stored in 10s of seconds, not in milliseconds.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Get rid of WaitCommEvent and using overlapped_armed to share the
same overlapped operation between read and select. Rather, make
sure to cancel the overlapped IO before leaving any of these functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Datatypes were incorrect, especially vmin_ and vtime_.
Change them to cc_t, as in user space.
- Error checking had a gap or two. Debug output used the
wrong formatting.
- Don't use ev member for ClearCommError and WaitCommEvent.
Both returned values are different (error value vs. event
code). The values are not used elsewhere so it doesn't make
sense to store them in the object. Therefore, drop ev member.
- Some variable names were not very helpful. Especially using
n as lpNumberOfBytesTransferred from GetOverlappedResult and
then actually printing it as if it makes sense was quite
puzzeling.
- Rework the loop and the definition of minchars so that it
still makes sense when looping.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- Don't use ev member for ClearCommError and WaitCommEvent.
Both returned values are different (error value vs. event
code). The values are not used elsewhere so it doesn't make
sense to store them in the object.
- Drop local variable ready which is used inconsequentially.
- Since WFSO already waits 10 ms, don't wait again if no char
is in the inbound queue.
- Avoid else if chains.
- Only print one line of debug output on error.
- Drop overlapped_armed < 0 check. This value is only set in
fhandler_serial::raw_read if VTIME > 0, and even then it's only
set to be immediately reset to 0 before calling ReadFile. So
overlapped_armed is never actually < 0 when calling select.
- Fix a screwed up statement order.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Add the missing mask for the decomposition of hi+lo which caused some
errors of 1-2 ULP.
This change is taken over from FreeBSD:
95436ce20d
Additionally I've removed some variable assignments which were never
read before being overwritten again in the next 2 lines.
This fix for k_tan.c is a copy from fdlibm version 5.3 (see also
http://www.netlib.org/fdlibm/readme), adjusted to use the macros
available in newlib (SET_LOW_WORD).
This fix reduces the ULP error of the value shown in the fdlibm readme
(tan(1.7765241907548024E+269)) to 0.45 (thereby reducing the error by
1).
This issue only happens for large numbers that get reduced by the range
reduction to a value smaller in magnitude than 2^-28, that is also
reduced an uneven number of times. This seems rather unlikely given that
one ULP is (much) larger than 2^-28 for the values that may cause an
issue. Although given the sheer number of values a double can
represent, it is still possible that there are more affected values,
finding them however will be quite hard, if not impossible.
We also took a look at how another library (libm in FreeBSD) handles the
issue: In FreeBSD the complete if branch which checks for values smaller
than 2^-28 (or rather 2^-27, another change done by FreeBSD) is moved
out of the kernel function and into the external function. This means
that the value that gets checked for this condition is the unreduced
value. Therefore the input value which caused a problem in the
fdlibm/newlib kernel tan will run through the full polynomial, including
the careful calculation of -1/(x+r). So the difference is really whether
r or y is used. r = y + p with p being the result of the polynomial with
1/3*x^3 being the largest (and magnitude defining) value. With x being
<2^-27 we therefore know that p is smaller than y (y has to be at least
the size of the value of x last mantissa bit divided by 2, which is at
least x*2^-51 for doubles) by enough to warrant saying that r ~ y. So
we can conclude that the general implementation of this special case is
the same, FreeBSD simply has a different philosophy on when to handle
especially small numbers.
Make line 47 in sf_trunc.c reachable. While converting the double
precision function trunc to the single precision version truncf an error
was introduced into the special case. This special case is meant to
catch both NaNs and infinities, however qNaNs and infinities work just
fine with the simple return of x (line 51). The only error occurs for
sNaNs where the same sNaN is returned and no invalid exception is
raised.
The comparison c == FP_INFINITE causes the function to return +inf as it
expects x = +inf to always be larger than y. This shortcut causes
several issues as it also returns +inf for the following cases:
- fdim(+inf, +inf), expected (as per C99): +0.0
- fdim(-inf, any non NaN), expected: +0.0
I don't see a reason to keep the comparison as all the infinity cases
return the correct result using just the ternary operation.
While testing the exp function we noticed some errors at the specified
magnitude. Within this range the exp function returns the input value +1
as an output. We chose to run a test of 1m exponentially spaced values
in the ranges [-2^-27,-2^-32] and [2^-32,2^-27] which showed 7603 and
3912 results with an error of >=0.5 ULP (compared with MPFR in 128 bit)
with the highest being 0.56 ULP and 0.53 ULP.
It's easy to fix by changing the magnitude at which the input value +1
is returned from <2^-28 to <2^-32 and using the polynomial instead. This
reduces the number of results with an error of >=0.5 ULP to 485 and 479
in above tests, all of which are exactly 0.5 ULP.
As we were already checking on exp we also took a look at expf. For expf
the magnitude where the input value +1 is returned can be increased from
<2^-28 to <2^-23 without accuracy loss for a slight performance
improvement. To ensure this was the correct value we tested all values
in the ranges [-2^-17,-2^-28] and [2^-28,2^-17] (~92.3m values each).
Passing a pointer to a local variable to WriteConsoleA is
not actually needed if we're not going to do anything with
what WriteConsoleA would put in there.
For the wpbuf class the pointer argument was made optional,
so it can be just left out; other call places now pass a
NULL pointer instead. The local variables `wn' and `n'
are no unused, so they go away.
Replace direct access to a pair of co-dependent variables
by calls to methods of a class that encapsulates their relation.
Also replace C #define by C++ class constant.
The single-precision trigonometric functions show rather high errors in
specific ranges starting at about 30000 radians. For example the sinf
procedure produces an error of 7626.55 ULP with the input
5.195880078125e+04 (0x474AF6CD) (compared with MPFR in 128bit
precision). For the test we used 100k values evenly spaced in the range
of [30k, 70k]. The issues are periodic at higher ranges.
This error was introduced when the double precision range reduction was
first converted to float. The shift by 8 bits always returns 0 as iq is
never higher than 255.
The fix reduces the error of the example above to 0.45 ULP, highest
error within the test set fell to 1.31 ULP, which is not perfect, but
still a significant improvement. Testing other previously erroneous
ranges no longer show particularly large accuracy errors.
- In xterm compatible mode, "ESC 7" and "ESC 8" do not work properly
in the senario:
1) Execute /bin/ls /bin to fill screen.
2) Sned CSI?1049h to alternate screen.
3) Reduce window size.
4) Send CSI?1049l to resume screen.
5) Send "ESC 7" and "ESC 8".
After sending "ESC 8", the cursor goes to incorrect position. This
patch adds a workaround for this issue.
- This patch fixes the issue that xterm compatible mode for input
is not correctly set/unset in some situation such as:
1) cat is stopped by ctrl-c.
2) The window size is changed in less.
In case 1), request_xterm_mode_input(true) is called in read(),
however, cat is stopped without request_xterm_mode_input(false).
In case 2), less uses longjmp in signal handler, therefore,
corresponding request_xterm_mode_input(false) is not called if
the SIGWINCH signal is sent within read(). With this patch,
InterlockedExchange() is used instead of InterlockedIncrement/
Decrement().
So far ioctl(TIOCINQ) could end up returning -1 with errno set to EINVAL
if a non-zero device error mask has been returned by ClearCommError.
This doesn't reflect Linux behaviour, which always returns the number of
chars in the inbound queue, independent of any I/O error condition.
EINVAL was a pretty weird error code to use in this scenario, too.
Fix this by dropping all checking for device errors in the TIOCINQ
case. Just return the number of chars in the inbound queue.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Most code in newlib already uses unified syntax, but just a couple of
laggards remain. This patch removes these and means the the entire
code base has now been converted.
- This patch makes some detailed behaviour of ESC sequences such as
"CSI Ps L" (IL), "CSI Ps M" (DL) and "ESC M" (RI) in xterm mode
match with real xterm.
fhandler_socket_unix::fixup_after_exec incorrectly calls
fhandler_socket_unix::fixup_after_fork with a NULL parent process
handle. Not only that calling DuplicateHandle with a NULL parent
handle fails, but it's utterly wrong trying to duplicate the handles
at all here.
Rather just set some important values to NULL and reopen the shared
memory region. Create a fixup_helper method to call common code from
fixup_after_fork and fixup_after_exec.
Add comments to other invocations of fixup_after_fork with NULL
handle to mark them as correct this way.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Aligning the stack pointer using an asm statement isn't any longer
supported. gcc-9.2.0 generates the following warning:
init.cc:33:46: error: listing the stack pointer register '%esp'
in a clobber list is deprecated [-Werror=deprecated]
[...]
init.cc:33:46: note: the value of the stack pointer after an
'asm' statement must be the same as it was before the statement
Replace the asm expression with the gcc function attribute
`force_align_arg_pointer'. This aligns the stack exactly as
required.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
reopen_shmem is accidentally called on the parent fhandler
rather than the child fhandler, and it's called too early.
Make sure to call it on the child and only after its shmem_handle
is valid.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Update dumper for bfd API changes in binutils 2.34
libbfd doesn't guarantee API stability, so we've just been lucky this
hasn't broken more often.
See binutils commit fd361982.
- In Win10 upto 1809, xterm compatible mode does not have REP
escape sequence which terminfo declares. This patch adds support
for "CSI Ps b" (REP). With this patch, bvi (binary editor) works
normally in Win10 1809. Also, xterm compatible mode does not have
"CSI Pm `" (HPA), "CSI Pm a" (HPR) and "CSI Ps e" (VPR). However,
they do not appear to be declared by terminfo. Therefore, these
have been pending.
- Cygwin console with xterm compatible mode causes problem reported
in https://www.cygwin.com/ml/cygwin-patches/2020-q1/msg00212.html
if background/foreground colors are set to gray/black respectively
in Win10 1903/1909. This is caused by "CSI Ps L" (IL), "CSI Ps M"
(DL) and "ESC M" (RI) control sequences which are broken. This
patch adds a workaround for the issue.
Corinna Vinschen
Åke Rehnman
Jon Turney
Fabian Schriever
Sebastian Huber
Takashi Yano via Cygwin-patches
Joel Sherrill
Takashi Yano
Hans-Bernhard Broeker
Richard Earnshaw