Age | Commit message (Collapse) | Author | Files | Lines |
|
without "_printf_float" being linked
Patch fixes wrong number of written characters being returend from 'printf'
family of functionsx when '_printf_float' is not linked (nano.specs). If user
tries to print a floating point number anyway, returned number of written
characters is not correct. For example in
printf("%d%f", 1, 1.0);
should return 1, but actaully returns 2.
|
|
sigaction() returns EINVAL on SIGKILL & SIGSTOP. We need to skip them.
Fixes: c7c1a1ca1b33 ("* libc/posix/posix_spawn.c: New file.")
|
|
setproctitle_init is defined in c2x manner, omitting names for
the unused parameters. This can result in warnings or errors
on certain compiler versions:
clang 8:
error: parameter name omitted
clang 15:
warning: omitting the parameter name in a function definition is a C2x
extension [-Wc2x-extensions]
gcc -Wsystem-headers -pedantic -std=c17:
warning: ISO C does not support omitting parameter names in function
definitions before C2X [-Wpedantic]
Add parameters to avoid above warning and errors.
Fixes: 2e7f7b96e5f1 ("Cygwin: implement setproctitle")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
This patch fixes "integer overflow" warning in arc4random.c. It explicitly
casts REKEY_BASE macro to size_t. The existing code relies on an implicit
conversion to int and assumes that sizeof(int)=sizeof(size_t), which is
not always true.
2025-03-02 Jan Dubiec <jdx@o2.pl>
newlib/ChangeLog:
* libc/stdlib/arc4random.c (REKEY_BASE): Explicitly cast the macro
to size_t.
newlib/libc/stdlib/arc4random.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
|
|
This patch fixes a few "left shift count >= width of type
[-Wshift-count-overflow]" warnings. Before shifting a char 16 (or more)
bits left first it explicitly casts the char to uint32_t. The existing
code relies on implicit casts to int and assumes that ints are 32-bit.
This is not always true because the C standard does not require int to
be 32-bit and there are targets (e.g. H8/300) where by default int is
indeed 16-bit.
2025-03-02 Jan Dubiec <jdx@o2.pl>
newlib/ChangeLog:
* libc/stdlib/gdtoa-gdtoa.c (gdtoa): Cast to __ULong before left shift.
* libc/string/memmem.c (memmem): Cast to uint32_t before left shift.
* libc/string/strstr.c (strstr2): Ditto.
(strstr3): Ditto.
(strstr4): Ditto.
newlib/libc/stdlib/gdtoa-gdtoa.c | 2 +-
newlib/libc/string/memmem.c | 3 ++-
newlib/libc/string/strstr.c | 6 +++---
3 files changed, 6 insertions(+), 5 deletions(-)
|
|
2025-03-02 Jan Dubiec <jdx@o2.pl>
newlib/ChangeLog:
* libc/sys/h8300hms/sbrk.c: Replace the K&R definition with the
standard one.
* libc/sys/h8300hms/syscalls.c (_isatty): Ditto.
(_unlink): Ditto.
newlib/libc/sys/h8300hms/sbrk.c | 3 +--
newlib/libc/sys/h8300hms/syscalls.c | 6 ++----
2 files changed, 3 insertions(+), 6 deletions(-)
|
|
This improves compatibility with clang that does not support vfpxd and does not need these extra directives.
Change-Id: Id2027e622aef8457ac9c7e1d6715a9240ce8e3f0
|
|
This is to improve compatibility with LLVM clang: .align 0 is a special case for GCC that is not handled by clang.
Change-Id: I855939a32294c74813ecce7275a362265dbc3b1a
|
|
The strcasecmp family of functions (strcasecmp, strncasecmp,
strcasecmp_l, strncasecmp_l) call tolower on the incoming
character before comparison. tolower takes an int as parameter.
All four strcasecmp functions neglect to cast the character to
unsigned before using it as parameter to tolower. This tolower
is called with negative values if the incoming character is not
in the ASCII range. This breaks case-insensitive comparison in
other singlebyte codesets like ISO-8859-1 with native characters.
Adding casts to unsigned char when calling tolower fixes it.
Reported-by: Bruno Haible <bruno@clisp.org>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
https://pubs.opengroup.org/onlinepubs/9799919799/functions/lseek.html
Signed-off-by: Christian Franke <christian.franke@t-online.de>
|
|
- related to Bug libc/32679
|
|
- fixes Bug libc/32679
|
|
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Some hardware may perform better when copying unaligned
word-sized memory compared to byte-by-byte copying.
In case not defined explicitly by --enable-newlib-hw-misaligned-access
config option or variable $default_newlib_hw_misaligned_access in
configure.host file the compiler check will be performed to detect if
__riscv_misaligned_fast or __riscv_misaligned_slow is defined.
This commit introduces autodetection for RISC-V. Additionally, checking
for __ARM_FEATURE_UNALIGNED could be checked for ARM architecture.
However, this was not implemented in the commit, as changes in
newlib/libc/machine/[arm|aarch64] need to be performed.
|
|
Prepare pointer to be aligned and than use word-size iterator on aligned
memory.
|
|
This change provides word-sized copy for overlapping buffers, that could
increase performance significantly. Performance measurement for RISCV:
uint8_t buf[1024];
memmove (buf + 4, buf, sizeof(buf) - 4);
CPU cycles: 12255 -> 2076
|
|
This change improves performance on memory blocks with sizes in range
[4..15]. Performance measurements made for RISCV machine (memset):
size 4, CPU cycles change: 50 -> 37
size 5, CPU cycles change: 57 -> 40
size 6, CPU cycles change: 64 -> 47
size 7, CPU cycles change: 71 -> 54
size 8, CPU cycles change: 78 -> 44
size 9, CPU cycles change: 85 -> 47
size 10, CPU cycles change: 92 -> 54
size 11, CPU cycles change: 99 -> 61
size 12, CPU cycles change: 106 -> 51
size 13, CPU cycles change: 113 -> 54
size 14, CPU cycles change: 120 -> 61
size 15, CPU cycles change: 127 -> 68
|
|
This change made just to have memccpy like others mem-functions
|
|
Move common macros to local.h header
|
|
add --enable-newlib-use-malloc-in-execl option
The previous version of these functions allocated a 256 entry array and
copied arguments in that array with no bound checking. That
implementation always occupied 1024 bytes of stack for the array even in
the common case in which the number of passed arguments is far less than
256, risking stack overflows in environments with small stacks, and
caused a stack buffer overflow if called with more than 256 arguments.
The improved implementation counts the actual number of passed arguments
and allocates a suitable buffer. The default implementation uses alloca
to allocate the buffer to satisfy the POSIX.1-2008 requirement that
execl and execle should be callable from signal handlers, but it is
possible to override this behavior and use malloc for targets where the
risk of stack overflow due to unbounded stack allocations is a more
pressing requirement than the corner case of allowing execl calls from
signal handlers.
|
|
The libc/sys/xtensa directory was removed in commit 48f1655c955c154b3165692e02aa66699212453c, but the change to Makefile.in wasn't committed.
|
|
Declare posix_close, a new function defined by POSIX-1.2024, per
https://pubs.opengroup.org/onlinepubs/9799919799/functions/posix_close.html
Define POSIX_CLOSE_RESTART.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
posix_devctl is now part of POSIX-1.2024, thus the requirement to
define _POSIX_26_C_SOURCE has been dropped.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
MISSING_SYSCALL_NAMES defined
If the macros REENTRANT_SYSCALLS_PROVIDED and MISSING_SYSCALL_NAMES are defined some
_reent_*-functions are replaced by the system-call and this leads to compile-warning
or a runtime-failure.
* newlib/libc/stdio/fopen.c _open_r is replaces by open(), declared in <fcntl.h>
* newlib/libc/stdio64/fopen64.c ditto
* newlib/libc/stdio/rename.c _rename_r is rename() itself; i.e, fix recursion
|
|
POSIX®.1-2024 now defines posix_spawn_file_actions_addchdir and
posix_spawn_file_actions_addfchdir. Add these interfaces to spawn.h,
guarded as POSIX 202405 symbols.
Cygwin-only: Export them as aliases of the *_np counterparts. Bump
API minor.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Regenerate Makefile.in.
Fixes: 71511d4ac8686 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft")
Reported-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
- bump up release to 4.5.0
|
|
In my build the below are treated as error now and causing failures. I
have described the fixes of each warning below.
In newlib/libc/sys/or1k/mlock.c:
CC libc/sys/or1k/libc_a-mlock.o
newlib/libc/sys/or1k/mlock.c: In function ‘__malloc_lock’:
newlib/libc/sys/or1k/mlock.c:56:19: warning: implicit declaration of function ‘or1k_critical_begin’ [-Wimplicit-function-declaration]
56 | restore = or1k_critical_begin();
| ^~~~~~~~~~~~~~~~~~~
newlib/libc/sys/or1k/mlock.c: In function ‘__malloc_unlock’:
newlib/libc/sys/or1k/mlock.c:93:17: warning: implicit declaration of function ‘or1k_critical_end’ [-Wimplicit-function-declaration]
93 | or1k_critical_end(restore);
| ^~~~~~~~~~~~~~~~~
This patch adds prototypes for functions or1k_critical_begin and
or1k_critical_end to suppress the warning, inline with what we do for
or1k_sync_cas.
In libgloss/or1k/or1k_uart.c:
libgloss/or1k/or1k_uart.c: In function ‘or1k_uart_set_read_cb’:
libgloss/or1k/or1k_uart.c:163:25: warning: passing argument 2 of ‘or1k_interrupt_handler_add’ from incompatible pointer type [-Wincompatible-pointer-types]
163 | _or1k_uart_interrupt_handler, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void (*)(uint32_t) {aka void (*)(long unsigned int)}
In file included from libgloss/or1k/or1k_uart.c:19:
libgloss/or1k/include/or1k-support.h:97:45: note: expected ‘or1k_interrupt_handler_fptr’ {aka ‘void (*)(void *)’} but argument is of type ‘void (*)(uint32_t)’ {aka ‘void (*)(long unsigned int)’}
97 | or1k_interrupt_handler_fptr handler,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
The public API is ‘void (*)(void *)' for our interrupt handlers. The
function _or1k_uart_interrupt_hander is the internal default
implementation of the uart IRQ handler and it doesn't use the data
argument.
This patch updates the _or1k_uart_interrupt_handler argument type from
uint32_t to void* allowing the function prototype to match the required
prototype.
If we did have a 64-bit implementation it would be an ABI issue. But,
there never has been one, or1k is only 32-bit.
In libgloss/or1k/interrupts.c:
libgloss/or1k/interrupts.c: In function ‘or1k_interrupt_handler_add’:
libgloss/or1k/interrupts.c:41:52: warning: assignment to ‘void *’ from ‘long unsigned int’ makes pointer from integer without a cast [-Wint-conversion]
41 | _or1k_interrupt_handler_data_ptr_table[id] = (uint32_t) data_ptr;
| ^
The table _or1k_interrupt_handler_data_ptr_table is an array of void*
and data_ptr is void*. There is no need for the cast so remove it.
In libgloss/or1k/sbrk.c:
libgloss/or1k/sbrk.c:23:29: warning: initialization of ‘uint32_t’ {aka ‘long unsigned int’} from ‘uint32_t *’ {aka ‘long unsigned int *’} makes integer from pointer without a cast [-Wint-conversion]
23 | uint32_t _or1k_heap_start = &end;
|
This patch adds a cast, which is safe in or1k as the architecture in
32-bit only. But this code would not be 64-compatible.
Signed-off-by: Stafford Horne <shorne@gmail.com>
|
|
Add SCHED_RESET_ON_FORK to <sys/sched.h>. If this flag is set, SCHED_FIFO
and SCHED_RR are reset to SCHED_OTHER and negative nice values are reset to
zero in each child process created with fork(2).
Signed-off-by: Christian Franke <christian.franke@t-online.de>
|
|
Add SCHED_BATCH to <sys/sched.h>. SCHED_BATCH is similar to SCHED_OTHER,
except that the nice value is mapped to a one step lower Windows priority.
Rework the mapping functions to ease the addition of this functionality.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
|
|
That according to C99/POSIX, nextafter(x,y) should return y if x==y.
[1] NetBSD fix for this: https://github.com/IIJ-NetBSD/netbsd-src/commit/3bc685224189d2b7dfb68da52d9725a256a667bd
[2] glibc fix for this: https://github.com/bminor/glibc/commit/bc9f6000f6752153e5e1902259d5f491a88a1ae5#diff-bcc0628a39c3c2003047dcb5a40a8b50c00f01a74b1c8c1100d770a8e48b1ce2
[3] Linux man page: https://man7.org/linux/man-pages/man3/nextafter.3.html
|
|
Add SCHED_IDLE to <sys/sched.h>. If SCHED_IDLE is selected, preserve
the nice value and set the Windows priority to IDLE_PRIORITY_CLASS.
Signed-off-by: Christian Franke <christian.franke@t-online.de>
|
|
|
|
The POSIX specification defines these as constants. The cast is
unnecessary. This brings newlib inline with the equivalent FreeBSD
defines.
|
|
_ISOC2x_SOURCE to _ISOC23_SOURCE
Signed-off-by: Lenard Mollenkopf <newlib@lenardmollenkopf.de>
|
|
|
|
Fixed another precision bug in powf(). This one is in the computation
[t=p_l+p_h High]. We multiply t by lg2_h, and want the result to be
exact. For the bogus float case of the high-low decomposition trick, we
normally discard the lowest 12 bits of the fraction for the high part,
keeping 12 bits of precision. That was used for t here, but it doesnt't
work because for some reason we only discard the lowest 9 bits in the
fraction for lg2_h. Discard another 3 bits of the fraction for t to
compensate.
This bug gave wrong results like:
powf(0.9999999, -2.9999995) = 1.0000002 (should be 1.0000001)
hex values: 3F7FFFFF C03FFFFE 3F800002 3F800001
As explained in the log for the previous commit, the bug is normally
masked by doing float calculations in extra precision on i386's, but is
easily detected by ucbtest on systems that don't have accidental extra
precision.
Reference: https://github.com/freebsd/freebsd-src/commit/5f20e5ce7f396ad064bfc1f45b8075ea1c0580f9
Original Author: Bruce Evans
|
|
(1) The bit for the 1.0 part of bp[k] was right shifted by 4. This
seems to have been caused by a typo in converting e_pow.c to
e_powf.c.
(2) The lower 12 bits of ax+bp[k] were not discarded, so t_h was
actually plain ax+bp[k]. This seems to have been caused by a logic
error in the conversion.
These bugs gave wrong results like:
powf(-1.1, 101.0) = -15158.703 (should be -15158.707)
hex values: BF8CCCCD 42CA0000 C66CDAD0 C66CDAD4
Fixing (1) gives a result wrong in the opposite direction
(hex C66CDAD8), and fixing (2) gives the correct result.
ucbtest has been reporting this particular wrong result on i386 systems
with unpatched libraries for 9 years. I finally figured out the extent
of the bugs. On i386's they are normally hidden by extra precision.
We use the trick of representing floats as a sum of 2 floats (one much
smaller) to get extra precision in intermediate calculations without
explicitly using more than float precision. This trick is just a
pessimization when extra precision is available naturally (as it always
is when dealing with IEEE single precision, so the float precision part
of the library is mostly misimplemented). (1) and (2) break the trick
in different ways, except on i386's it turns out that the intermediate
calculations are done in enough precision to mask both the bugs and
the limited precision of the float variables (as far as ucbtest can
check).
ucbtest detects the bugs because it forces float precision, but this
is not a normal mode of operation so the bug normally has little effect
on i386's.
On systems that do float arithmetic in float precision, e.g., amd64's,
there is no accidental extra precision and the bugs just give wrong
results.
Reference: https://github.com/freebsd/freebsd-src/commit/12be4e0d5a54a6750913aee2564d164baa71f0dc
Original Author: Bruce Evans
|
|
The decomposition needs to be into 12+24 bits of precision for extra-
precision multiplication, but was into 13+24 bits. On i386 with -O1 the
bug was hidden by accidental extra precision, but on amd64, in 2^32
trials the bug caused about 200000 errors of more than 1 ulp, with a
maximum error of about 80 ulps. Now the maximum error in 2^32 trials
on amd64 is 0.8573 ulps. It is still 0.8316 ulps on i386 with -O1.
The nearby decomposition of 1/ln2 and the decomposition of 2/(3ln2) in
the double precision version seem to be sub-optimal but not broken.
Reference: https://github.com/freebsd/freebsd-src/commit/b4437c3d322a0f6d23d12b6f76d2fc72d2ff0ec2
Original Author: Bruce Evans
|
|
|
|
when a C++ source file include this header file, it would build fail.
Signed-off-by: yang.zhang <zhangyang01@kylinos.cn>
|
|
Support dirent in *-esp-* toolchains
|
|
Remove sys/xtensa that is actually duplicate newlib's code.
Move used code to machine/xtensa or to libgloss
|
|
nl_langinfo_l accesses lc_messages_T::codeset as soon as
__HAVE_LOCALE_INFO__ is defined, but codeset only exists
if __HAVE_LOCALE_INFO_EXTENDED__ is defined.
Fix this by defining lc_messages_T::codeset depending on
__HAVE_LOCALE_INFO__.
Fixes: ac7f1d5e931c ("Get rid of LCID, reformat type definitions in setlocale.h")
Reported-by: Inglis <Brian.Inglis@SystematicSW.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
The nl_ext array contains offsets into the extended info of
locale structures, the index being equivalent to the nl_item
values in langinfo.h.
For the lc_messages_T struct, nl_ext erroneusly contains an
entry for the codeset member, which is in fact not part of the
extended info in nl_item. However, due to that, the offsets for
subsequent entries are off by one.
Fix this by dropping the messages::codeset entry from nl_ext.
Fixes: d47d5b850bed ("Extend locale support to maintain wide char values of native strings")
Reported-by: Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
|
|
Synopsys ARCv3 ISA includes 32-bit ARC HS5x targets and
64-bit ARC HS6x targets. Both CPU families are placed
in "arc64" subdirectories as it done for GCC port.
Target name arc64 is used for historical reasons and
Synopsys ARCv3 baremetal toolchains contain multilib
configurations both for 32-bit and 64-bit families.
arc32 target name is reserved for 32-bit ARC HS5x
targets in case of non-multilib 32-bit builds.
Note that libgloss libraries for ARCv3 are compatible with
libgloss for ARCv1/2. Thus, Makefile.inc for libgloss uses
sources from libgloss/arc directory except crtX.S files.
Co-authored-by: Shahab Vahedi <list@vahedi.org>
Co-authored-by: Claudiu Zissulescu <claziss@gmail.com>
Co-authored-by: Bruno Mauricio <brunoasmauricio@gmail.com>
Co-authored-by: Luis Silva <luis.m.silva99@hotmail.com>
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
|
|
This variable was accidentally renamed earlier. It must be
ldflags according to DejaGNU documentation.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
|
|
There's no semantic change, it's only to make the same code
compilable with MetaWare toolchian, which actually assumes
@x as a full name, not omitting @.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
Replace __ARC_ALIGNED_ACCESS__ macro with the compiler defined
macro __ARC_UNALIGNED__ and improve file comments.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
|
|
Fixed glob() function to return GLOB_NOMATCH if pattern does
not match any existing pathname (and GLOB_NOCHECK was not set in flags).
|