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.
This constant was missing in unistd.h and some applications
use it to check for pthread barriers support.
Signed-off-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
ticket : #13601
Thus, BeOS compatibility is preserved (and there is no risk of
breaking GCC5<->GCC2 interoperation on hybrid builds.)
This commit only makes the actual change, the build fixes are
in the next commit.
These were added in C99 to avoid interferring with C++, but then C++11
caught up with inttypes/h/stdint.h and removed the need for the macros.
They have disappeared from C11 as a result, and also from current glibc
implementation (https://sourceware.org/bugzilla/show_bug.cgi?id=15366)
So it seems reasonably safe to do the same, and it will save people
having to enable access to these macros explicitly when writing C++.
This reverts commit 17286dc70a.
As discussed on the mailing list. As it turns out, this was less
than half of an actual implementation of this macro, and there's
technically no way to implement it without introducing (theoretical)
race conditions, in the current design anyway.
limits.h is part of the C standard, but POSIX and XSI extend it with
various defines. We should not add these unless the application requests
support for them.
In this case, PAGE_SIZE should only be defined if XSI support is
requested by defining _XOPEN_SOURCE. Note that PAGESIZE (plain POSIX for
the same thing) and B_PAGE_SIZE are alternatives that remain available.
This is an implementation of pthread barriers pursuant to the relevant specification.
Barriers are essentially a special case of conditional variables,
such that all threads waiting on one are woken up when the number of
waiters reaches a number provided at the initialization of the barrier.
In view of that, this implementation mimics the implementation of pthread_cond,
except it is more specialized and self-contained.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
The warnings made those headers and those including them not detectable
by libiberty's configure because of the way it checked for them.
This fixes the gcc build.
