Commit Graph

747 Commits

Author SHA1 Message Date
Jérôme Duval
a866e2d902 POSIX: introduce sem_clockwait
will appear in the next version: https://www.opengroup.org/austin/docs/austin_1110.pdf

Change-Id: Iee3faf23647aa5244ad316fe1c3d825592483935
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4966
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
2022-02-18 21:27:06 +00:00
Alexander von Gluck IV
901fc0c75f posix/arch/signal: Fix riscv64 arch detection
* We decided to not create our own custom define checks
  and go with the standard ones for riscv64.
* clang doesn't define __RISCV64__ either, so this moves
  the clang build of riscv64 a bit further

Change-Id: I2a6c3751168a898c1617b32f46055a9ba1609e2b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4861
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
2022-01-12 12:17:15 +00:00
Jérôme Duval
a7115745f2 POSIX/C11: add timespec_get()
Change-Id: I746e32f3a463bf2c7b03097c625901d54cf2b8eb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4853
Reviewed-by: Rene Gollent <rene@gollent.com>
2022-01-10 14:46:27 +00:00
Augustin Cavalier
7db2616c44 dirent: Use an actual flexible-length array for d_name.
GCC 11 treats [1] as a fixed-length array and not a flexible-length
array, and so some things that used direct strcmp("..", ent->d_name),
for instance, would be optimized out as being always unequal,
which was the cause of #17389. Using a real FLA informs GCC that
there is going to be more than one byte of data, and thus this
fixes that bug.

BeOS used [1] and not [0], possibly because it had to deal with
compilers (MetroWerks? Early GCC2?) that did not support FLAs.
GCC 2.95 does, using [0], and GCC 4 does, using [], so we can go
with that here.

(I did try using [0] for both, which seems to be OK with GCC 11,
but GCC 8 throws errors when d_name is dereferenced directly
as being-out-of-bounds. So, we have to use the #if here and give
newer GCC the [] syntax and not [0] to avoid that problem.)

The real question probably is whether or not we should backport
some variant of these changes to R1/beta3, as software at HaikuPorts
very well may run in to the same issue. (The alternative workaround
is to compile with -O1 and not -O2 for any affected software.) But
maybe this is an argument for keeping with the beta4 schedule of
this coming January...
2021-11-18 16:34:03 -05:00
Augustin Cavalier
1e541d3127 stdlib.h: Remove guards around aligned_alloc.
While FreeBSD and glibc feature-guard it, they also feature-guard
a lot of other things that we don't, and musl does not guard it,
so it seems more than safe enough to leave it unguarded.

Fixes compilation errors with GCC 11. (The other possible solution
was including features.h in more places, but this seems simpler.)
2021-11-16 15:13:29 -05:00
Fredrik Holmqvist
48eb7d981d Allow gcc to know result is aligned
Someone on the internet found out gcc only understand posix_memalign.

The alloc_align attribute may be applied to a function that returns
a pointer and takes at least one argument of an integer or enumerated
type. It indicates that the returned pointer is aligned on a boundary
given by the function argument at position.

Change-Id: I4b0af6ef3020da1fb460652117286193d5d72f1e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4514
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
2021-10-14 16:19:18 +00:00
Augustin Cavalier
5e2d0005c1 libroot: Fix previous commit. 2021-09-17 15:35:51 -04:00
Augustin Cavalier
ffbe2ad946 libroot: Reinstate tdestroy.
It was removed in hrev55422 as we never had declared it in any headers.
But it seems some software came to depend on it anyway. Reinstate it,
and add a declaration for it, behind _GNU_SOURCE.
2021-09-17 15:34:10 -04:00
Alexander von Gluck IV
372b901dfe riscv: cleanup architecture macro checks
* We really should get out of the habbit of making up
  our own architecture defines.
* __riscv with an additional  __riscv_xlen is the
  standard that developed... let's just roll with it.

Change-Id: Ieb777d48340ae25a6d66f66133afa0ec5c6da9b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4402
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2021-09-01 18:04:59 +00:00
X512
4a32f48e70 kernel/arch/thread: implement for riscv64
Change-Id: I3effa598626b32c29606299cd0edee390d430baf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4066
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
2021-08-06 15:01:52 +00:00
Jérôme Duval
ddffdd2506 C11: define __STDC_NO_THREADS__ as threads.h is not provided
Theorically we could define __STDC_NO_THREADS__ internally in GCC, but
threads.h probably will be added in the future, and the compiler won't
notice.
Using this stdc-predef.h header and including it in GCC would solve this
nicely, and saves us from hardcoding.
The header can eventually be removed when obsolete.

Change-Id: I29aa58686e3c45449dc63e02e5a9e13a960b9090
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-06-21 12:31:53 +00:00
Jérôme Duval
7d961f9746 sys/resource.h: add rusage compatibility fields, set to zero
POSIX defines this structure but specifies only two fields (which we
already implement). However, both the *BSD and Linux have agreed on
some more fields, which are often assumed to be there by applications.

The benefice of having compatibility fields is
greater as having to patch every other software at HaikuPorts.

Change-Id: Ie28ca2e348aa16b4c57eb3498eb62175100d9b9d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4083
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2021-06-20 12:50:24 +00:00
Jérôme Duval
c6fe367365 POSIX: introduce ppoll
will appear in the next version: https://www.opengroup.org/austin/docs/austin_1110.pdf

Change-Id: I38014ad910881df260f0ec762831491e143328c4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4099
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-06-19 18:09:25 +00:00
Alexander von Gluck IV
ad284e7acb ifconfig: expand 10Gbps media knowledge
* These are pretty much the 10G standards that have
  any potential for usage on a desktop system.

Change-Id: I2cb49f41ca61e82e091d042f877ee2f1acb9c4ec
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3900
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-05-05 12:52:12 +00:00
Jérôme Duval
7065a89fc6 POSIX: ioctl(fd, op, arg) equals ioctl(fd, op, arg, 0)
The ioctl call cannot know the expected number of arguments
because it depends on the specific ioctl being used, and the
same value could be used to do different things by different
devices. Without knowing that, it is not safe to use va_arg
(at best a random value will be read from the stack, at worst,
it will just crash).

This changes the implementation of ioctl in two ways:
- For C++ code: a 4 argument function with default values
  for arguments 3 and 4.
- For C code: wrap arguments 3 and 4 in a struct with the
  help of a macro, providing something that behaves like the
  C++ version.

So, with this new code:
- Calling ioctl with only 3 arguments sets the 4th one to 0
- Calling ioctl with only 2 arguments sets the 3rd and 4th to 0
- Calling with 1 or 5+ arguments is a compile time error

The existing ioctl symbol is preserved for ABI compatibility.

Change-Id: I6d4d1d38fccd8cc9bd94203d3e11aeac6da8efc3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3360
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-05-04 19:21:48 +00:00
Jérôme Duval
3592432e9b utmpx.h: add ut_host for compatibility (not posix)
Change-Id: I27e8f7b6dbc29232542e3749d8e194efa2ef5209
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3799
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-03-16 16:55:44 +00:00
Niels Sascha Reedijk
fc03b45a71 POSIX: make readv() and writev() conform to IEEE Std 1003.1-2001
The standardized version of readv() and writev() take an int as the third
parameter. Arguably a size_t makes more sense, but the standardization bodies
decided otherwise.

The non-standard functions of readv_pos() and writev_pos() have been updated
for consistency. The corresponding _kern_readv() and _kern_writev() internal
functions continue to take the size_t parameter.

The ABI will not change, even though on 64 bit machines the size of the count
parameter will change from 8 to 4 bytes.

The actual use will be slightly different. Like with the size_t argument type,
it will not be possible to give a count lower than 0. If the value is less than
0, then the B_BAD_VALUE/EINVAL error will be set.

Change-Id: I949c8ed67dbc0b4e209768cbdee554c929fc242e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3770
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2021-03-16 12:03:02 +00:00
Jérôme Duval
acdafb571d Debugger: fix build after hrev54931 2021-01-29 21:38:10 +01:00
Adrien Destugues
6f3a5c9ab0 Debugger: add AVX support
- Unify storage of "FPU" registers between debugger and signal handler
  to use xsave format on both sides
- Handle YMM registers in Debugger (they are the same as XMM, but wider)

Tested:
- The system still boots with and without AVX
- The hello_avx test program can be debugged and the full value of YMM is visible

This changes the API of vregs in signal.h but not the ABI (structure are
declared differently but memory layout is the same). This changes the
API and ABI of arch_debugger.h for x86_64, but I don't think anything
outside Haiku uses it (did we ever have a 64bit compatible gdb?)

Change-Id: If93680ffa0339c19bab517876b4e029f5d66b240
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3038
Reviewed-by: Rene Gollent <rene@gollent.com>
2021-01-29 13:29:10 +00:00
Jérôme Duval
9a7acbdbcf posix: protect EOF being parsed as operator and 1
see 7d095c7453/dev-libs/jsoncpp/patches/jsoncpp-1.9.4.patchset

Change-Id: Iaedb67eb51e86cbc5b73a21a86b6b0b6b70209b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3679
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2021-01-25 18:53:43 +00:00
Adrien Destugues
68d37cfb3a Fix definition of PAGESIZE and B_PAGE_SIZE
On sparc, the minimal page size we can use is 8K. Since B_PAGE_SIZE and
PAGESIZE defines were hardcoded to 4K, this resulted in a lot of
confusion in all code trying to manipulate pages.

- Remove cpu.h from headers/private/kernel/arch/*. It dates back from
  NewOS and was not used anymore since our kernel uses B_PAGE_SIZE
  (PAGE_SIZE was the only thing defined in this header).
- Add posix/arch/*/limits.h with the arch specific page size and include
  it from the main limits.h.
- Adjust bios_ia32/debug.cpp which was the only place using the
  PAGE_SIZE constant from the deleted headers.
- Change OS.h to define B_PAGE_SIZE to be the same as POSIX PAGESIZE.
- Define PAGESIZE in the build header if the host OS doesn't.

Change-Id: I8c3732cf952ea3c2f088aa16d216678fbf198b96
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3558
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2021-01-08 12:02:16 +00:00
Adrien Destugues
a959262cd0 implement mlock(), munlock()
Change-Id: I2f04b8986d2ed32bb4d30d238d668e21a1505778
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1991
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-12-03 07:58:05 +00:00
Jérôme Duval
c5ff1f14c6 syslog.h: add LOG_PRIMASK and LOG_PRI macros
Change-Id: I9ae0c3165cea831e329e49211ff738cbb89a65de
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3408
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2020-11-22 09:28:57 +00:00
Jérôme Duval
2982d9819f fcntl.h: define O_DIRECT directly
coreutils wants to undefine O_NOCACHE, this shouldn't affect O_DIRECT though.

Change-Id: Id00316a78eb91b2c7f692bb46eca65b3a7983c6f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3398
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-11-20 18:23:35 +00:00
Jérôme Duval
a1999d3b8a POSIX: add tcsetsid()
Change-Id: Ia8f41e417379dcaf4f976933cf91bb2de157bc72
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3376
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-11-17 07:53:28 +00:00
Jérôme Duval
e04970ad6f POSIX: add utmpx.h and function stubs
OpenJDK 14 assumes symbols and headers are available.

Change-Id: I21038e92afcfd2000ee95712bce874afd29611b6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3371
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-11-17 07:46:30 +00:00
Jérôme Duval
a9c09fcaae POSIX: lseek: support SEEK_DATA and SEEK_HOLE constants
this is queued for issue 8: https://www.austingroupbugs.net/view.php?id=415
this implementation calls the ioctl hook of the filesystem with BSD-like constants
FIOSEEKDATA and FIOSEEKHOLE. if the hook doesn't know the constants, we use the stat size
to return the last hole (as proposed in the draft spec).

Change-Id: I5d052eed87e29b70491a7ff534e244896469d03e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3385
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2020-11-12 10:42:11 +00:00
Jérôme Duval
fe357eb9c9 POSIX: add posix_fallocate and a preallocate syscall
the preallocate syscall will call the preallocate filesystem hook, if available.

fix #6285

Change-Id: Ifff4595548610c8e009d4e5ffb64c37e0884e62d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3382
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2020-11-12 10:41:21 +00:00
Jérôme Duval
b05d6f0af0 POSIX: asprintf and vasprintf are BSD/GNU extensions
fix #16259

Change-Id: Ia16bb6e1944b87b25d1a940bbdaaf6e236db1abf
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3381
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-11-07 08:49:34 +00:00
Jérôme Duval
6878792ae4 C11: add aligned_alloc()
Change-Id: If648c0e27ed946874d393e8e33a4548b70c8ecdb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3377
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-11-04 21:01:42 +00:00
Jérôme Duval
b48159dce2 POSIX: add tcgetsid()
Change-Id: If58141b4e56b7fe444460b6808e33abc5ea71f37
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3374
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
2020-11-04 06:18:17 +00:00
Jérôme Duval
7335fb0d5c in6.h: declare in6_addr with a union and extra fields
According to https://tools.ietf.org/html/rfc3493:
3.2 IPv6 Address Structure
"The structure in6_addr above is usually implemented with an embedded
union with extra fields that force the desired alignment level in a
manner similar to BSD implementations of "struct in_addr"."

Change-Id: Ibe0ee685366398c143cdf9573dcb77566a12888b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3348
Reviewed-by: Rene Gollent <rene@gollent.com>
2020-10-23 08:13:03 +00:00
Jérôme Duval
d504f219f4 POSIX: add _SC_TTY_NAME_MAX
Change-Id: Ifa24f68535d7a4a4c5fe3f01e63fe2c87adcc429
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3340
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
2020-10-23 07:08:03 +00:00
Jérôme Duval
db9d2a6f14 POSIX: add dprintf
Change-Id: I577d5283a9be04924a8dd05c3be3969b41da60db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3282
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-10-04 19:34:40 +00:00
François Revol
425515d0ac m68k: really add fenv from musl-1.1.24
Somehow the first review merged only the commit log.

FreeBSD doesn't have m68k anyway, so use fenv from musl with as less
changes as possible.

Change-Id: I6372af6679e6773fbb6bf4c8b5b30512971a97a6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3161
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
2020-08-19 15:23:47 +00:00
rofl0r
7de1ebe0d6 netdb.h: fix prototype of gethostbyaddr()
first parameter should be const void*, in line with freebsd and linux etc.

https://xref.landonf.org/source/xref/freebsd-current/include/netdb.h#232

Change-Id: I5e953e8e7e49a6f09cd1143de6ca57eb98f77d73
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3147
Reviewed-by: Michael Lotz <mmlr@mlotz.ch>
2020-08-17 00:08:02 +00:00
Michael Lotz
b3bd66961a libroot/kernel: Implement MADV_FREE madvise() extension.
It allows an application to signal that it no longer needs the data in
the given address range and the underlying pages can be discarded and
reused elsewhere. This is finer grained than working with full areas
or mappings at a time and enables unmapping sections of partially used
mappings without giving up its address space.

Compared with punching holes into a mapping by "mapping over" with
PROT_NONE and MAP_NORESERVE, this has the obvious advantage of not
producing a lot of unused extra areas and saves the corresponding
resources. It is also a lot "lighter" of an operation than cutting
existing areas.

This introduces madvise() alongside the existing posix_madvise() to
allow for OS specific extensions. The constants for both functions are
aliased, the POSIX_MADV_* being a subset of the MADV_* ones without the
non-POSIX extensions. Internally posix_madvise() simply calls madvise().

MADV_FREE is commonly supported in other OSes with various subtle
semantic differences as to when pages are actually freed/cleared and how
or whether the pages are counted against the memory use of a process.
In the variant implemented here, pages are always immediately discarded
and memory counting is not altered. This behaviour should be considered
an implementation detail and may be altered later. The actual unmap and
discard could for example be delayed until pages are needed elsewhere to
reduce overhead in case of repeated discarding and remapping.

Note that MADV_FREE doesn't really align with the rest of the madvise()
API as it works like a command (i.e. discard these pages) and does not
add an attribute to the pages in the given range (i.e. mark these pages
for quick access from now on). As such, an MADV_FREE does not need to be
undone by setting a different advice later on, unlike how the other
flags work. This discrepancy may be the reason why it is not part of
POSIX.

Change-Id: Icc093379125a43e465dc4409d8f5ae0f64e107e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2844
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2020-08-01 19:23:27 +00:00
Adrien Destugues
4bfc0072e3 limits.h: ncrease ARG_MAX
The limit was set when creating limits.h back in hrev88. It seems to be
used only in glob(). The limit is quite low by today standards and
prevents building icu 67.

I guess the liit was put at 32K because that's what BeOS did, but I see
no reason to keep it that way.

Change-Id: I74f95d9b56891dd90c79b7ced35ca8d1ec81d6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3117
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2020-08-01 17:37:01 +00:00
Augustin Cavalier
8da1468de6 arpa/nameser.h: Fix build on GCC8.
ssize_t comes from sys/types.h.
2020-07-03 15:30:00 -04:00
Augustin Cavalier
657f041aee fnmatch: Replace BSD implementation with musl one.
The BSD implementation was under the Advertising Clause,
so we might as well take the opportunity to replace the
implementation entirely with musl's.

Header also rewritten to be a Haiku one; the constants
are left unchanged of course.
2020-07-03 15:09:33 -04:00
Augustin Cavalier
6996e5b271 headers: More removal of the BSD Advertising Clause.
Taken from FreeBSD; some minor cleanup elsewhere.

udp.h rewritten entirely as it contained no copyrightable
material and bears little resemblance to BSD's.
2020-07-03 15:00:37 -04:00
Augustin Cavalier
ebffd73fc5 arpa/nameser.h: Cleanup.
* Remove functions not even FreeBSD defines.
 * Remove dependency on unnecessary headers.
 * Update copyright headers to match FreeBSD's; includes
   removal of the advertising clause.
 * Move some private structs to netresolv port_before.

Unfortunately, it seems musl implements very little of this file,
so we may wind up sticking with netresolv for its implementation.
2020-07-03 14:27:17 -04:00
Augustin Cavalier
2ed1a36d4b resolv.h & netdb.h: Clean up and simplify.
* Remove all functions and a number of constants that neither
   glibc nor musl define or support (and even FreeBSD does not
   declare a good number of these anymore.)
 * Redeclare the primary flags in terms of (1 << X) instead
   of raw 0x... for readability (the constants at the end
   do NOT match up to their definitions in glibc, musl, and BSDs!)
 * Remove usage of unneeded headers, and __BEGIN/END_DECLS.
 * Replace non-Haiku license headers with the ones from FreeBSD,
   which notably contain a removal of the advertising clause.

ABIs remain unchanged, but a small set of applications that
use these esoteric APIs may not compile anymore (are there
any remaining?)
2020-07-02 19:33:51 -04:00
Augustin Cavalier
17dab0d52b inet.h: Remove "cidr" functions.
These are not in the standard and are not declared by glibc at all.
The symbols remain for any applications that are still using them,
for now.\

Change-Id: Ie6b4a6b5ec3231c304e05ce9cb38c67d9ee51ad7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2942
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
2020-06-22 16:02:31 +00:00
Jérôme Duval
9495126984 kernel/x86_64: AVX support
xsave or xsavec are supported.
breaks vregs compatibility.
change the thread structure object cache alignment to 64
the xsave fpu_state size isn't defined, it is for instance 832 here, thus I picked 1024.

Change-Id: I4a0cab0bc42c1d37f24dcafb8259f8ff24a330d2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2849
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-06-03 06:16:48 +00:00
François Revol
8a9a366fef strings.h: s/inline/__inline__/
As suggested by http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Inline.html

This should fix building things like NBDkit.

Change-Id: I1da7fc140dd8451ff2ddaf599fe4e951401d0cb3
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2794
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
2020-05-24 13:59:57 +00:00
Augustin Cavalier
9304fbae8a uchar.h: Remove duplicate definition of mbrtoc32. 2020-05-09 16:15:55 -04:00
Adrien Destugues
22337d8f4b uchar.h: char16_t must be uint_least16_t
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>
2020-05-09 19:29:28 +00:00
Michael Lotz
b94221f3b2 mmap: Use MAP_NORESERVE to request overcommit, not PROT_NONE.
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>
2020-05-09 02:57:48 +00:00
Adrien Destugues
2dc597d50d Optimize ffs() implementation
- 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>
2020-05-08 14:01:53 +00:00