We attempted to make it a 32bit char type, but that is actually not allowed
unless we also make uint_least16_t a 32bit type. And even then, we
wouldn't be allowed to store or handle values wider than 16bit.
Comply more closely to the standard. As a result, mbtoc16r is not
implemented. c16rtomb is implemented by casting the char to 32bit, which
isn't really correct either (I think you're supposed to be able to feed
the two halves of a > 16bit codepoint in two separate calls and get a
meaningful result out?)
Related to #15990 but we may want an actual implementation?
Change-Id: If8198675c27dd2aa412bc44d12d3df4e31d3e8c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2623
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reverts hrev54120 and instead adds the commonly supported
MAP_NORESERVE flag to request overcommit.
Using PROT_NONE for overcommit is problematic as the protection of
individual pages can still be changed via mprotect to make them
accessible, but that won't change the commitment. An application
using such a pattern may then unexpectedly run into out of memory
conditions on random writes into the address space.
With MAP_NORESERVE the overcommit can explicitly be requested by
applications that want to reserve address space without producing
memory pressure.
Change-Id: Id213d2245c5e23103e8e0857f7902e0cd8a2c65d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2611
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
- Use gcc builtin
- Define as a static inline function in the .h so no function call overhead is needed
- Keep the function in libroot for backwards compatibility
- Remove a duplicate implementation in the freebsd compatibility layer
gcc2 does not document the builtin, but it is in fact already available
there as well.
Fixes#3281.
Change-Id: I94f8a2548637aa70e85febbfab06f07c1a427005
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2605
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It was not specified as such before C11, but that's only because there
was no C standard way to do it until then.
Fixes#15955.
Change-Id: Ied7b7fd94988ed7724460917aebc859b74eaa585
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2558
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* A few tips for future folks follows.
* fenv.h gets wrapped in our buildtools
* If anything in the arch fenv.h "doesn't work" buildtools
will silently fail early on (autotools HAVE_FENV_H)
Change-Id: Icae064fde42af3bbed5ea2eadfaa8c18c677e6a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2164
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Borrowed from FreeBSD with some changes to get it building.
Now we need to rebuild the gcc package...
Change-Id: I6b8dfd7fb6ca912c76e2ff10fbe01ad583a09aec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2131
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
glibc does the same. Technically, some of these builtins did
not exist / did not work before GCC 4.4, but the source tree
cannot be compiled with a version that old anyway.
x86_64 and _x86 need to keep the old functions for now, of
course; but all other architectures can probably feel free
to drop the s_isnan, etc. functions from their glibc.
This will make upcoming patches easier...
Change-Id: Ifb76ea74076553228c9741a8ee3ecb0e1cf736a3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
For #15515
As mentionned in the ticket, we may also want to hide the symbols
altogether from libroot for newer API/ABI versions, unless we still want
to provide C89/C99/C++98/C++11 compatibility, in which case we still
need them around.
Change-Id: I0ee267fb6c4c2f4bae9b1ba6f68e2bcefc399a7f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Discovered this while working on VLC, checked with other online sources too.
Change-Id: I114c20babda0ff0e90d0eeee299d8483700166bd
Reviewed-on: https://review.haiku-os.org/c/1628
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
should help for ports.
Change-Id: Id504bdb79cb68db4b615f58848e0e1a86ced8d2b
Reviewed-on: https://review.haiku-os.org/c/1467
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* Oops, there's a standard for these. Stick to the standard.
* Add a few that could be useful someday.
* Mention iana spec.
Change-Id: I4cf75e8c1e4b25f65d10921c7075fbd53f44e14e
Fixes the build breakage caused by PulkoMandy's recent commit.
Remove these from ByteOrder.h now also, as per POSIX they should
come from netinet/in.h.
This is a small source compatibility breakage, but it will only
affect a small portion of non-POSIX, partially-Be applications.
Gets the stage0 bootstrap to run.
Imlementation is probably nonsense at this point.
Change-Id: I10876efbb54314b864c0ad951152757cdb2fd366
Reviewed-on: https://review.haiku-os.org/c/1061
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Implemented against POSIX-1.2013.
The implementation POSIX requirement thats setpriority() shall affect the
priority of all system scope threads only extends to POSIX threads. This
is implemented by modifying the default attributes for newly spawned
pthreads.
It is not possible to modify the default pthread attributes for different
processes with the current implementation, as default pthread attributes
are implemented in user-space. As a result, PRIO_PROCESS for which and 0
for who is the only supported combination for setpriority().
While it is possible to move the default attributes to the kernel, it
is chosen not to so as to keep the pthread implementation user-space only.
POSIX requires that lowering the nice value (increasing priority) can be
done only by processes with appropriate privileges. However, as Haiku
currently doesn't harbor any restrictions in setting the thread priority,
this is not implemented.
It is possible to have small precision errors when converting from Unix-
style thread priority to Be-style. For example, the following program
outputs "17" instead of the expected "18":
#include <stdio.h>
#include <sys/resource.h>
int
main()
{
setpriority(PRIO_PROCESS, 0, 18);
printf("%d\n", getpriority(PRIO_PROCESS, 0));
return 0;
}
The underlying reason is because when you setpriority() both 18 and 19
are converted to the Be-style "2". This problem should not happen with
priority levels lower than or equal to 20, when the Be notation is more
precise than the Unix-style.
Done as a part of GCI 2014. Fixes#2817.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Co-authored-by: Leorize <leorize+oss@disroot.org>
Change-Id: Ie14f105b00fe8563d16b3562748e1c2e56c873a6
Reviewed-on: https://review.haiku-os.org/c/78
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should prevents GCC from throwing -Werror=return-type when
pthread_exit is used in place of return
Change-Id: Ied7da58b671e77b53d859b67193259aa78ec27d6
Reviewed-on: https://review.haiku-os.org/632
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* gcc 7.x defines __arm__ and __ARM__ (and others)
* clang defines __arm__ and __arm
* cleanup a few related ifdef vs if macros
Change-Id: I5da4bafac590f6fa3e10e543688001c2449f840d
FreeBSD's is presently 46 bytes. CID 1422869 warns that it can get overrun
in if_attach() in copying if_xname which is IF_NAMESIZE bytes (32).
This breaks ABI, but BeOS did not have sockaddr_dl, it is only a modern-GCC
ABI break. Since most applications assume that sockaddr_dl is variable-length
and is null-terminated, as well as not used very often, hopefully this will
require relatively few rebuilds.
Not in the POSIX specification, but defined (not behind any guards)
in (at least) FreeBSD, NetBSD, glibc, and macOS.
Found by miqlas and myself while working on porting GNU inetutils.
