The 'cygnus' option was removed from automake 1.13 in 2012, so the
presence of this option prevents that or a later version of automake
being used.
A check-list of the effects of '--cygnus' from the automake 1.12
documentation, and steps taken (where possible) to preserve those
effects (See also this thread [1] for discussion on that):
[1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html
1. The foreign strictness is implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
2. The options no-installinfo, no-dependencies and no-dist are implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
Future work: Remove no-dependencies and any explicit header dependencies,
and use automatic dependency tracking instead. Are there explicit rules
which are now redundant to removing no-installinfo and no-dist?
3. The macro AM_MAINTAINER_MODE is required.
Already present in newlib/acinclude.m4
Note that maintainer-mode is still disabled by default.
4. Info files are always created in the build directory, and not in the
source directory.
This appears to be an error in the automake documentation describing
'--cygnus' [2]. newlib's info files are generated in the source
directory, and no special steps are needed to keep doing that.
[2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html
5. texinfo.tex is not required if a Texinfo source file is specified.
(The assumption is that the file will be supplied, but in a place that
automake cannot find.)
This effect is overriden by an explicit setting of the TEXINFO_TEX
variable (the directory part of which is fed into texi2X via the
TEXINPUTS environment variable).
6. Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
For obscure automake reasons, this effect of '--cygnus' is not active
for makeinfo in newlib's configury.
However, there appears to be top-level configury which selects in-tree
runtest, expect and makeinfo, if present. So, if that works as it
appears, this effect is preserved. If not, this may cause problem if
anyone is building those tools in-tree.
This effect is not preserved for texi2dvi. This may cause problems if
anyone is building texinfo in-tree.
If needed, explicit checks for those tools looking in places relative to
$(top_srcdir)/../ as well as in PATH could be added.
7. The check target doesn't depend on all.
This effect is not preseved. The check target now depends on the all
target.
This concern seems somewhat academic given the current state of the
testsuite.
Also note that this doesn't touch libgloss.
- This patch uses gdtoa imported from OpenBSD if newlib configure
option "--enable-newlib-use-gdtoa=no" is NOT specified. gdtoa
provides more accurate output and faster conversion than legacy
ldtoa, while it requires more heap memory.
- If the number has large integer part and small fraction part is
specified in output format, e.g. printf("%.3f", sqrt(2)*1e60);,
valid output digits were insufficient. This patch fixes the issue.
https://cygwin.com/pipermail/cygwin/2021-November/249930.html
reported a regression introduce by using a dynamically sized local
char array in favor of a statically sized array.
Fix this by reverting to a statically sized array, using a small
buffer on the stack for a reasonable number of requested digits, a
big mallocated buffer otherwise. This should work for small targets
as well, given that malloc is used in printf anyway right now.
This is *still* hopefully just a temporary measure, unless somebody
actually provides a new ldtoa.
Fixes: 4d90e53359 ("ldtoa: fix dropping too many digits from output")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
ldtoa cuts the number of digits it returns based on a computation of
number of supported bits (144) divide by log10(2). Not only is the
integer approximation of log10(2) ~= 8/27 missing a digit here, it
also fails to take really small double and long double values into
account.
Allow for the full potential precision of long double values. At the
same time, change the local string array allocation to request only as
much bytes as necessary to support the caller-requested number of
digits, to keep the stack size low on small targets.
In the long run a better fix would be to switch to gdtoa, as the BSD
variants, as well as Mingw64 do.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When newlib is configured with --enable-newlib-reent-check-verify,
the assert macro is already defined in the nano-mallocr.c compile unit.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
_strtod_l as well as the gethex function both fetch the decimal point
from the current LC_NUMERIC locale info. This pulls in _C_numeric_locale
unconditionally even on targets not supporting locales at all.
Another problem is that strtod.c and gdtoa-gethex.c are ELIX 1, while
locale information in general isn't. This leads to potential build
breakage on bare metal targets.
Fix this by setting the decimal point to "." on all targets not
defining __HAVE_LOCALE_INFO__.
While at it, const'ify the entire local decimal point info in the
affected functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The C standard says that errno may acquire the value ERANGE if the
result from strtod underflows. According to IEEE 754, underflow occurs
whenever the value cannot be represented in normalized form.
Newlib is inconsistent in this, setting errno to ERANGE only if the
value underflows to zero, but not for denorm values, and never for hex
format floats.
This patch attempts to consistently set errno to ERANGE for all
'underflow' conditions, which is to say all values which are not
exactly zero and which cannot be represented in normalized form.
This matches glibc behavior, as well as the Linux, Mac OS X, OpenBSD,
FreeBSD and SunOS strtod man pages.
Signed-off-by: Keith Packard <keithp@keithp.com>
The only reason why it is tough for us to use nano malloc
is because of the small shortcoming where nano_malloc()
splits a bigger chunk from the free list into two pieces
while handing back the second one (the tail) to the user.
This is error prone and especially bad for smaller heaps,
where nano malloc is supposed to be superior. The normal
malloc doesn't have this issue and we need to use it even
though it costs us ~2k bytes compared to nano-malloc.
The problem arise especially after giving back _every_
malloced memory to the heap and then starting to exercise
the heap again by allocating something small. This small
item might split the whole heap in two equally big parts
depending on how the heap has been exercised before.
I have uploaded the smallest possible application
(only tested on ST and Nordic devices) to show the issue
while the real customer applications are far more complicated:
https://drive.google.com/file/d/1kfSC2KOm3Os3mI7EBd-U0j63qVs8xMbt/view?usp=sharing
The application works like the following pseudo code,
where we assume a heap of 100 bytes
(I haven't taken padding and other nitty and gritty
details into account. Everything to simplify understanding):
void *ptr = malloc(52); // We get 52 bytes and we have
// 48 bytes to use.
free(ptr); // Hand back the 52 bytes to nano_malloc
// This is the magic line that shows the issue of
// nano_malloc
ptr = malloc(1); // Nano malloc will split the 52 bytes
// in the free list and hand you a pointer
// somewhere in the
// middle of the heap.
ptr2 = malloc(52); // Out of memory...
I have done a fix which hands back the first part of the
splitted chunk. Once this is fixed we obviously
have the 1 byte placed in position 0 of the heap instead
of somewhere in the middle.
However, this won't let us malloc 52 new bytes even though
we potentially have 99 bytes left to use in the heap. The
reason is that when we try to do the allocation,
nano-malloc looks into the free list and sees a 51 byte
chunk to be used.
This is not big enough so nano-malloc decides to call
sbrk for _another_ 52 bytes which is not possible since
there is only 48 bytes left to ask for.
The solution for this problem is to check if the last
item in the free list is adjacent to sbrk(0). If it is,
as it is in this case, we can just ask sbrk for the
remainder of what is needed. In this case 1 byte.
NB! I have only tested the solution on our ST device.
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>
Without this, for a bare-iron/simulator target such as cris-elf,
you'll see, at newlib build time:
/x/gccobj/./gcc/xgcc -B/x/gccobj/./gcc/ <many options elided> -c -o lib_a-aligned_alloc.o \
`test -f 'aligned_alloc.c' || echo '/y/newlib/libc/stdlib/'`aligned_alloc.c
/y/newlib/libc/stdlib/aligned_alloc.c: In function 'aligned_alloc':
/y/newlib/libc/stdlib/aligned_alloc.c:35:10: warning: implicit declaration of function \
'_memalign_r' [-Wimplicit-function-declaration]
35 | return _memalign_r (_REENT, align, size);
| ^~~~~~~~~~~
The overflow check in mEMALIGn erroneously checks for INT_MAX,
albeit the input parameter is size_t. Fix this to check for
__SIZE_MAX__ instead. Also, it misses to check the req against
adding the alignment before calling mALLOc.
While at it, add out-of-bounds checks to pvALLOc, nano_memalign,
nano_valloc, and Cygwin's (unused) dlpvalloc.
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"
commit 588a5e1dde added a non-reentrant
call to nano_malloc which causes a build failure if INTERNAL_NEWLIB is
defined.
Here is a snippet of the error:
In file included from .../newlib/newlib/libc/stdlib/nano-mallocr.c:38:
.../newlib/newlib/libc/include/malloc.h:42:25: note: expected 'struct _reent *' but argument is of type 'ptrdiff_t' {aka 'int'}
42 | extern void *_malloc_r (struct _reent *, size_t);
| ^~~~~~~~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:67:22: error: too few arguments to function '_malloc_r'
67 | #define nano_malloc _malloc_r
| ^~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:456:11: note: in expansion of macro 'nano_malloc'
456 | mem = nano_malloc(bytes);
| ^~~~~~~~~~~
In file included from .../newlib/newlib/libc/stdlib/nano-mallocr.c:38:
.../newlib/newlib/libc/include/malloc.h:42:14: note: declared here
42 | extern void *_malloc_r (struct _reent *, size_t);
| ^~~~~~~~~
.../newlib/newlib/libc/stdlib/nano-mallocr.c:43: warning: "assert" redefined
43 | #define assert(x) ((void)0)
|
This patch adds a missing RCALL to the args when calling nano_malloc
from nano_calloc, so that if the call is reentrant, reent_ptr is passed
as the first argument.
The variable `bytes` (also added in 588a5e1d) has been changed from a
`ptrdiff_t` to `malloc_size_t` as it does not need to be signed. It is
used to store the product of two unsigned malloc_size_t variables and
then iff there was no overflow is it passed to malloc and memset which
both expect size_t which is unsigned.
Signed-off-by: Craig Blackmore <craig.blackmore@embecosm.com>
This built-in function (available in both gcc and clang) is more
efficient and generates shorter code than open-coding the test.
Signed-off-by: Keith Packard <keithp@keithp.com>
The original implementation had multiple issues:
- Only worked when posix_memalign was available (Linux, RTEMS).
- Violated C11 link namespace rules by calling posix_memalign.
- Failed to set errno on error.
These can be fixed by essentially using the same implementation
for aligned_alloc as for memalign, i.e. simply calling _memalign_r
(which is always available and a "more reserved name" although
technically still not in the reserved link namespace, at least
code written in c cannot define a colliding symbol, newlib has
plenty such namespace issues so this is fine).
It is not clear what the right policy is when MALLOC_PROVIDED is set,
currently that does not cover aligned_alloc so it is kept that way.
Tested on aarch64-none-elf
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>
In the two helper functions that _dcvt calls for 'f' and 'e' mode, if
there are no digits to display after the decimal point, don't add one.
Signed-off-by: Keith Packard <keithp@keithp.com>
Leading zeros after the decimal point should not count
towards the 'ndigits' limit.
This makes gcvt match glibc and the posix gcvt man page.
Signed-off-by: Keith Packard <keithp@keithp.com>
Even if the number is really small and this means showing *no* digits.
This makes newlib match glibc, and the fcvt posix man page.
Signed-off-by: Keith Packard <keithp@keithp.com>
- add new eBalloc macro to mprec.h which calls Balloc and
aborts if Balloc fails due to out of memory
- change mprec.c functions that use Balloc without checking to use eBalloc instead
- fix dtoa.c to use eBalloc
Commit fbace81684
("Import correctly working strtold from David M. Gay.")
introduced two new files, strtorx.c and strtodg.c. The functions
are only called from strtold.c. However, while strtold.c is only
built if HAVE_LONG_DOUBLE is defined, the patch erroneously added
the two new files to GENERAL_SOURCES unconditionally.
Fix this by building both files only if HAVE_LONG_DOUBLE has been
defined.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Commit 6c212a8b78
("Fix strtod ("nan") and strtold ("nan") returns wrong negative NaN")
introduced an unconditional dependency to nanl and, in turn, to libm.
Rather than including nanl in libc as well, just call __builtin_nanl
from here. Requires GCC 3.3 or later.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The string/float conversion functions need to get the locale decimal
point. Instead of calling __localeconv_l (which copies locale data
into lconv form from __get_numeric_locale), use __get_numeric_locale
directly.
Signed-off-by: Keith Packard <keithp@keithp.com>
strtof ("-nan") returned positive NaN instead of negative NaN.
strtod ("-nan") and strtold ("-nan") return negative NaN.
Linux glibc has been fixed
that strto{f|d|ld} ("-nan") returns negative NaN.
https://sourceware.org/bugzilla/show_bug.cgi?id=23007
This commit makes strtof preserves the negative sign bit
when parsing "-nan" like glibc.
By previous commit, strto{d|ld} ("nan")
does not use the definition of NaN.
There is no other function that uses the definitions.
This commit remove the definitions.
The definition of qNaN for x86_64 and i386 was wrong.
strto{d|ld} ("nan") returned wrong negative NaN
instead of correct positive NaN
since it used the wrong definition.
On the other hand, strtof ("nan") returns correct positive NaN
since it uses nanf ("") instead of the wrong definition.
This commit makes strto{d|ld} ("nan") uses {nan|nanl} ("")
like strtof ("nan") using.
So strto{d|ld} ("nan") returns positive NaN.
Previously, "test 1 2 3 -a -b -c" was permuted to "test -a -b -c 1 2 3",
but "test 1 2 3 -abc" was left as "test 1 2 3 -abc".
Signed-off-by: Thomas Kindler <mail+newlib@t-kindler.de>
- when calculating a correction to align next brk to page boundary,
ensure that the correction is less than a page size
- if allocating the correction fails, ensure that the top size is
set to brk + sbrk_size (minus any front alignment made)
Signed-off-by: Jeff Johnston <jjohnstn@redhat.com>
- From: Cesar Philippidis <cesar@codesourcery.com>
Date: Tue, 10 Apr 2018 14:43:42 -0700
Subject: [PATCH] nvptx port
This port adds support for Nvidia GPU's, which are primarily used as
offload accelerators in OpenACC and OpenMP.
The gdtoa implementation uses the type long, defined as Long, in lots
of code. For historical reason newlib defines Long as int32_t instead.
This works fine, as long as floating point exceptions are not enabled.
The conversion to 32 bit int can lead to a FE_INVALID situation.
Example:
const char *str = "121645100408832000.0";
char *ptr;
feenableexcept (FE_INVALID);
strtod (str, &ptr);
This leads to the following situation in strtod
double aadj;
Long L;
[...]
L = (Long)aadj;
For instance, on x86_64 the code here is
cvttsd2si %xmm0,%eax
At this point, aadj is 2529648000.0 in our example. The conversion to
32 bit %eax results in a negative int value, thus the conversion is
invalid. With feenableexcept (FE_INVALID), a SIGFPE is raised.
Fix this by always using 64 bit ints here if double is not a 32 bit type
to avoid this type of FP exceptions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch fixes a syntax error in exit.c that was introduced during the
ANSI-fication of newlib. The patch fixes a compile-time issue that arises when
newlib is configured with the --enable-lite-exit feature.
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>
The variable doesn't follow the convention of having the same name as
the function it's bundled with. Furthermore, it clashes with the
variable of the same name in newlib/libc/stdlib/calloc.c.
Signed-off-by: Florian Schmidt <florian.schmidt@neclab.eu>
Some architectures like ARM encode the short enum option state in the
object file and the linker checks that this option is consistent for all
objects of an executable. In case applications use -fno-short-enums,
then this leads to linker warnings. Use the enum __packed attribute for
the relevent enums to avoid the -fshort-enums compiler option. This
attribute is at least available on GCC, LLVM/clang and the Intel
compiler.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Newlib build system defines __SINGLE_THREAD__ to allow concurrency code
to be only compiled when newlib is configured for multithread. One such
example are locks which become useless in single thread mode. Although
most static locks are indeed guarded by !defined(__SINGLE_THREAD__),
some are not.
This commit adds these missing guards to __dd_hash_mutex,
__atexit_recursive_mutex, __at_quick_exit_mutex and __arc4random_mutex.
It also makes sure locking macros in lock.h are noop in single thread
mode.
In preparation for the patch that would allow retargeting of locking
routines, rename all lock objects to follow this pattern:
"__<name>_[recursive_]mutex".
Following locks were renamed:
__dd_hash_lock -> __dd_hash_mutex
__sfp_lock -> __sfp_recursive_mutex
__sinit_lock -> __sinit_recursive_mutex
__atexit_lock -> __atexit_recursive_mutex
_arc4random_mutex -> __arc4random_mutex
__env_lock_object -> __env_recursive_mutex
__malloc_lock_object -> __malloc_recursive_mutex
__atexit_mutex -> __at_quick_exit_mutex
__tz_lock_object -> __tz_mutex
Hi,
With the patch to allow newlib's locking routine to be retargeted currently
under discussion, we need to start thinking of locks as part of newlib's ABI
since newlib depends on specific names being provided by the OS. This patch
renames 2 locks so that they follow the same naming convention as other locks.
It needs to be applied before the retargeting patch, while locks are still an
internal consideration.
Newlib builds successfully with this change.
Ok for master branch?
Best regards,
Thomas
This patch adds further comments to nano-mallocr.c, to more comprehensively
explain how padding works in the malloc_chunk structure.
It was originally discussed in the following thread:
https://sourceware.org/ml/newlib/2017/msg00031.html
2017-01-13 Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (malloc_chunk, get_chunk_from_ptr)
(nano_malloc): Add comments.
As described in nano-mallocr.c, chunks of heap are represented in memory
as a size (of type long), followed by some optional padding containing a
negative offset to size, followed by the data area.
get_chunk_from_ptr is responsible for taking a pointer to the data area
(as returned by malloc) and finding the start of the chunk. It does this
by assuming there is no padding and trying to read the size, if the size
is negative then it uses that as an offset to find the true size.
Crucially, it reads the padding area as a long.
nano_malloc is responsible for populating the optional padding area. It
does so by casting a pointer to an (int *) and writing the negative
offset into it.
This means that padding is being written as an int but read as a long.
On msp430 an int is 2 bytes, while a long is 4 bytes. This means that 2
bytes are written to the padding, but 4 bytes are read from it: it has
only been partially initialised.
nano_malloc is the default malloc implementation for msp430.
This patch changes the cast from (int *) to (long *). The change to
nano_malloc has has been observed to fix a TI Energia project that
had been malfunctioning because malloc was returning invalid addresses.
The change to nano_memalign is based entirely on code inspection.
I've built and tested as follows:
Configured (gcc+newlib) with: --target=msp430-elf --enable-languages=c
gcc testsuite variations:
msp430-sim/-mcpu=msp430
msp430-sim/-mcpu=msp430x
msp430-sim/-mcpu=msp430x/-mlarge/-mdata-region=either/-mcode-region=either
msp430-sim/-mhwmult=none
msp430-sim/-mhwmult=f5series
My testing has shown no regressions, however I don't know if the gcc
testsuite provides sufficient coverage for this patch?
I don't have write access, so if this patch is acceptable after review,
I would appreciate it if someone would commit it for me.
Thanks,
2017-01-XX Joe Seymour <joe.s@somniumtech.com>
newlib/
* libc/stdlib/nano-mallocr.c (nano_malloc): Fix incorrect cast.
(nano_memalign): Likewise.
* libc/stdlib/strtod.c (strtof_l): Set errno to ERANGE when double to
float conversion results in infinity.
(strtof): Likewise.
* libc/stdlib/wcstod.c (wcstof_l): Likewise.
(wcstof): Likewise.
make pdf on arm-none-eabi targets fails to build after the reorganization in
baf0c9fcb5 to fold is*_l documentation in their
is* counterpart. This is due two issues:
1) newlib/libc/ctype/ctype.tex still including the def file for the long versions
2) missing angle brackets in .c files for some of is*_l functions
This patch fixes the issues and allows make pdf to succeeds.
- Remove charset parameter from low level __foo_wctomb/__foo_mbtowc calls.
- Instead, create array of function for ISO and Windows codepages to point
to function which does not require to evaluate the charset string on
each call. Create matching helper functions. I.e., __iso_wctomb,
__iso_mbtowc, __cp_wctomb and __cp_mbtowc are functions returning the
right function pointer now.
- Create __WCTOMB/__MBTOWC macros utilizing per-reent locale and replace
calls to __wctomb/__mbtowc with calls to __WCTOMB/__MBTOWC.
- Drop global __wctomb/__mbtowc vars.
- Utilize aforementioned changes in Cygwin to get rid of charset in other,
calling functions and simplify the code.
- In Cygwin restrict global cygheap locale info to the job performed
by internal_setlocale. Use UTF-8 instead of ASCII on the fly in
internal conversion functions.
- In Cygwin dll_entry, make sure to initialize a TLS area with a NULL
_REENT->_locale pointer. Add comment to explain why.
Signed-off by: Corinna Vinschen <corinna@vinschen.de>
Newlib defines defaults for internal types via <sys/_types.h> and uses
<machine/_types.h> to let targets define their own type if necessary.
Previously for example
#ifndef __dev_t_defined
typedef short __dev_t;
#endif
However, the __*_t_defined pattern conflicts with the glibc type guard
pattern for user types, e.g. dev_t in this example. Introduce a
__machine_*_t_defined pattern for internal types (defined by
<machine/_types.h>, used by <sys/_types.h>). For example
#ifndef __machine_dev_t_defined
typedef short __dev_t;
#endif
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Intel MCU System V ABI are incompartible with i386 System V ABI:
o Minimum instruction set is Intel Pentium ISA minus x87 instructions
o No x87 or vector registers
o First three args are passed in %eax, %edx and %ecx
o Full specification available here:
https://github.com/hjl-tools/x86-psABI/wiki/iamcu-psABI-0.7.pdf
newlib/
* configure.host: Add new ix86-*-elfiamcu target
newlib/libc/include/
* setjmp.h: Change _JBLEN for Intel MCU target
newlib/libc/machine/i386/
* memchr.S: (memchr) Target-specific size-optimized version
* memcmp.S: (memcmp) Likewise
* memcpy.S: (memcpy) Likewise
* memmove.S: (memmove) Likewise
* memset.S: (memset) Likewise
* setjmp.S: (setjmp) Likewise
* strchr.S: (strchr) Likewise
* strlen.S: (strlen) Likewise
newlib/libc/stdlib/
* srtold.c: (__flt_rounds) Disable for Intel MCU
Prototypes also added for initstate() and setstate() but they
were not implemented in the shared newlib code.
* newlib/libc/include/cygwin/stdlib.h: Prototypes added.
* winsup/cygwin/include/cygwin/stdlib.h: Prototypes removed.
* newlib/libc/stdlib/random.c: New file.
* newlib/libc/machine/epiphany/machine/stdlib.h: Removed
* newlib/libc/stdlib/Makefile.am: Added random.c.
* newlib/libc/stdlib/stdlib.tex: Added random.def.
* newlib/libc/stdlib/Makefile.in: Regenerated.
Infinity returned from strtold is recognized as NaN by GCC builtin
functions. The reason is that ULtox is missing to set a bit.
* libc/stdlib/strtorx.c (ULtox): Set high bit in second word
to create valid Infinity value.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
newlib:
* libc/stdlib/arc4random.h: Remove Cygwin-specific locking code.
Conditionalize arc4 locking. Check for _ARC4_LOCK_INIT being
undefined to fall back to default implementation.
cygwin:
* include/machine/_arc4random.h: New file.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
According to the OpenBSD man page, "A Replacement Call for Random". It
offers high quality random numbers derived from input data obtained by
the OpenBSD specific getentropy() system call which is declared in
<unistd.h> and must be implemented for each Newlib port externally. The
arc4random() functions are used for example in LibreSSL and OpenSSH.
Cygwin provides currently its own implementation of the arc4random
family. Maybe it makes sense to use this getentropy() implementation:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/crypto/getentropy_win.c?rev=1.4&content-type=text/x-cvsweb-markup
* libc/include/stdlib.h (arc4random): Declare if __BSD_VISIBLE.
(arc4random_buf): Likewise.
(arc4random_uniform): Likewise.
* libc/include/sys/unistd.h (getentropy): Likewise.
* libc/include/machine/_arc4random.h: New file.
* libc/stdlib/arc4random.c: Likewise.
* libc/stdlib/arc4random.h: Likewise.
* libc/stdlib/arc4random_uniform.c: Likewise.
* libc/stdlib/chacha_private.h: Likewise.
* libc/sys/rtems/include/machine/_arc4random.h: Likewise.
* libc/stdlib/Makefile.am (EXTENDED_SOURCES): Add arc4random.c
and arc4random_uniform.c.
* libc/stdlib/Makefile.in: Regenerate.
Jon Turney
Takashi Yano
Corinna Vinschen
Mike Frysinger
Torbjorn SVENSSON via Newlib
Keith Packard
Ola Olsson
Hans-Peter Nilsson
Corinna Vinschen
Jozef Lawrynowicz
Craig Blackmore
Szabolcs Nagy
Jeff Johnston
Bruno Haible
uchan-nos
Jon Beniston
Masamichi Hosoda
Aditya Upadhyay
Thomas Kindler
Jaap de Wolff
Orlando Arias
Yaakov Selkowitz
Florian Schmidt
Sebastian Huber
Thomas Preud'homme
Freddie Chopin
Thomas Preudhomme
Joe Seymour
Andre Vieira (lists)
Igor Venevtsev
Joel Sherrill
Howland, Craig D