- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
of frexpl() function. With this patch, frexpl() function has been
implemented in libm to solve this issue.
Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
svfwscanf replaces getwc and ungetwc_r. The comments in the code talk
about avoiding file operations, but they also need to bypass the
mbtowc calls as svfwscanf operates on wchar_t, not multibyte data,
which is a more important reason here; they would not work correctly
otherwise.
The ungetwc replacement has code which uses the 3 byte FILE _ubuf
field, but if wchar_t is 32-bits, this field is not large enough to
hold even one wchar_t value. Building in this mode generates warnings
about array overflow:
In file included from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/stdio/vfwscanf.c: In function '_sungetwc_r.isra':
../../newlib/libc/stdio/vfwscanf.c:316:12: warning: array subscript 4294967295 is above array bounds of 'unsigned char[3]' [-Warray-bounds]
316 | fp->_p = &fp->_ubuf[sizeof (fp->_ubuf) - sizeof (wchar_t)];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../newlib/libc/stdio/stdio.h:46,
from ../../newlib/libc/stdio/vfwscanf.c:82,
from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/include/sys/reent.h:216:17: note: while referencing '_ubuf'
216 | unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
| ^~~~~
However, the vfwscanf code *never* ungets data before the start of the
scanning operation, and *always* ungets data which matches the input
at that point, so the code always hits the block which backs up over
the input data and never hits the block which uses the _ubuf field.
In addition, the svfwscanf code will always start with the unget
buffer empty, so the ungetwc replacement never needs to support an
unget buffer at all.
Simplify the code by removing support for everything other than
backing up over the input data, leaving the check to make sure it
doesn't get underflowed in case the vfscanf code has a bug in it.
Signed-off-by: Keith Packard <keithp@keithp.com>
The scanf code was skipping the '0' after the 'x' causing the
resulting buffer to contain an invalid number when passed to strtod.
Signed-off-by: Keith Packard <keithp@keithp.com>
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures. A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.
Introduce a new configure variable called "shared_machine_dir". This
dir can then be used for headers shared between architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The MSP430 target supports both 16-bit and 20-bit size_t and intptr_t.
Some implicit casts in Newlib expect these types to be
"long", (a 32-bit type on MSP430) which causes warnings during
compilation such as:
"cast from pointer to integer of different size"
This edits licenses held by Berkeley and NetBSD, both of which
have removed the advertising requirement from their licenses.
Signed-off-by: Keith Packard <keithp@keithp.com>
This reverts commit 59362c80e3.
This breaks gnulib's autoconf test for POSIX compatibility of
fflush/fseek. After fflush/fseek, ftello and lseek are out of
sync, with lseek having the wrong offset. This breaks backward
compatibility with Cygwin applications.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The call to fflush was invalidating the read buffer, preventing relative
seeks to positions that would have been inside the read buffer from
being optimized. The call to srefill would then re-read mostly the same
data that was initially in the read buffer.
newlib's vfwscanf(3) (or specifically, __SVFWSCANF_R()) fails to correctly set
the assignment-suppressing character (`*') flag[1] which, when present in the
formatting string, results in undefined behaviour comprising retrieving and
dereferencing a pointer that was not supplied by the caller as such or at all.
When compared to the vfscanf(3) implementation, this would appear to be over
the missing goto match_failure statement preceded by the flags test seen below.
Hence, this patch (re)introduces it.
[1] <http://pubs.opengroup.org/onlinepubs/009695399/functions/fwscanf.html>
--
This fix is for some platforms which do not have writev().
*perror.c: Use _write_r() instead of writev().
*psignal.c: Use write() insetad of writev().
Revise commit: d4f4e7ae1b
Code path for _MB_CAPABLE scans for the '%' character and advances
'fmt' pointer past '%'. Code path for !_MB_CAPABLE leaved fmt pointing
to '%', which caused the state machine to go from START to DONE state
immediately.
Neither upstream FreeBSD nor glibc ever call fflush from ftell
and friends. In border cases it has the tendency to return
wrong or unexpected values, for instance on block devices.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Discard QUICKREF sections, rather than writing them to stderr
Discard MATHREF sections, rather than discarding as an error
Pass NOTES sections through to texinfo, rather than discarding as an error
Don't redirect makedoc stderr to .ref file
Remove makedoc output on error
Remove .ref files from CLEANFILES
Regenerate Makefile.ins
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Old BSD bug: While ^ is recognized and the set of matching characters
is negated, the code neglects to increment the pointer pointing to the
matching characters. Thus, on a negation expression like %[^xyz], the
matching doesn't only stop at x, y, or z, but incorrectly also on ^.
Fix this by setting the start pointer after recognizing the ^.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* vfscanf: per POSIX, if the target type is wchar_t, the width is
counted in (multibyte) characters, not in bytes.
* vfscanf: Handle UTF-8 multibyte sequences converted to surrogate
pairs on UTF-16 systems.
* vfwscanf: Don't count high surrogates in input against field width
counting. Per POSIX, input is
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The width value keeps the maximum field width. This is the maximum
field width of the *input*. It's *never* to be used in conjunction
with the number of bytes or characters written to the output argument.
However, especially in vfwscanf, the code is partially taken from
NetBSD which erroneously subtracts the number of multibyte chars
written to the argument from the width variable, thus potentially
subtracting up to MB_CUR_MAX from width for a single character in
the input stream.
To make matters worse, the previous patch adding %m added basically
the same mistake for 'c' type input.
Fix it.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
* The new code is guarded with _WANT_IO_POSIX_EXTENSIONS, but
this is automatically enabled with _WANT_IO_C99_FORMATS for now.
* vfscanf neglects to implement %l[, so %ml[ is not implemented yet
either.
* Sidenote: vfwscanf doesn't allow ranges in %[ yet. Strictly this
is allowed per POSIX, but it differes from vfscanf as well as from
glibc.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The special handling of %\0 in [w]scanf is flawed. It's just a
matching failure and should be handled as such. scanf also
fakes an int input value on %X with X being an invalid conversion
char. This is also just a matching failure and should be handled
the same way as %\0.
There's no indication of the reason for this "disgusting
backwards compatibility hacks" in the logs, given this
code made it into newlib before setting up the CVS repo.
Just handle these cases identically as matching failures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>