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...
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.)
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>
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.
* 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>
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>
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>
* 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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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.
Taken from FreeBSD; some minor cleanup elsewhere.
udp.h rewritten entirely as it contained no copyrightable
material and bears little resemblance to BSD's.
* 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.
* 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?)
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>
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>
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>
