This file should ideally contain only those things needed
across all system headers, even POSIX ones, and all other
declarations (B_* ones especially) should go in SupportDefs.h.
However, as nothing but riscv64 uses this right now, I've just
moved it to there.
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...
At present, it does, but that is an oddity we have preserved from BeOS
that the next commit is going to remove. (This commit thus wastes 1 byte
without the following one.)
Most changes are pretty straightforward: only a +1 is needed,
and a few removed from sizing calculations. Some filesystems like UDF
originally passed back the length with the \0 included, so they have
been adjusted further. UFS2 had some other sizing problems which are also
corrected in this commit.
Our dirent structure is "slim": it has a flexible-length array at the
end which must be allocated to whatever size the consumer wants. However,
we use [1] there and not [0] or [], which meant GCC thought it was not
a flexible-length array, and so it optimized various string accesses
that it assumed must be always false. Among these was BDirectory's
check for "." and "..", and so that resulted in infinite loops.
When changing our dirent structure to a proper FLA instead of [1],
GCC then throws errors on LongDirEntry as it has data "after" the
FLA; which is what we want, but there is no way to tell GCC that.
So now we use a union instead, which is the proper way to statically
allocate a FLA.
This is part of #17389, but the real fix requires changing our dirent
structure, which is coming in a separate commit.
As suggested by PulkoMandy. This was done before my commits yesterday,
but those just reverted patches that had only been in since May,
so it's not clear how much this is actually needed. Nonetheless
it seems like the more correct thing to do.
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.)
The use of the "register" keyword is harmless, though we should eventually
remove it.
Taking addresses of packed members is "mostly harmless" on x86 where
unaligned accesses are OK. It's less harmless on other architectures,
but we sometimes use packed structures when manually aligning things.
Unfortunately GCC throws this warning even when the actual pointer would
be aligned, not merely when it's unaligned, making the warning far too
noisy and not really that useful.
"Found" by GCC 11.
It seems lowntfs and libntfs-3g kind of assume there is something in here.
This may result in broken links, but that's better than crashing.
Should fix#17400.
It is now at https://review.haiku-os.org/admin/repos/jamfile-engine
This was added in the Haiku repository in the intent of adding it to
release images, a long time ago. Now with the packaging system in place,
there is no reason to host it in the main repo anymore (and it was never
actually packaged anyway).
I also added a recipe at haikuports for it.
Fixes#5360.
Change-Id: I4f2a1529cbadf7af8a16025c30a1332108475807
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4720
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Intel recommends first checking for the existence of CPUID leaf 1FH before using leaf 0BH.
Change-Id: Iba677186521e086fa06bcc4fe42eaed4ba030e6d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4719
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
I found this at the bottom of my TODO list…
- UdpDomainSupport methods were referring to the object through a static
variable when they could just use the "this" object instead.
- Use BAutoDeleter to simplify the code a little
- Style problem (missing != NULL in pointer check)
- Move referencing of domainSupport in _GetDomainSupport instead of
OpenEndpoint. This way the two _GetDomainSupport methods both return
an already referenced object
Thanks to Axel for the code review and sorry for the super late reply.
Change-Id: Ic50ebb1a63a203d5aa393d28f4631c345acacc79
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3908
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Due to how API versions work, it seems this flag is still applied
on a lot of applications, as some have some rather old API versions
(actually API versions themselves may not be working quite right, to boot.)
All relevant software should have had a chance to be recompiled on
or after beta2, so we reduce the flag's automatic application back
just to BeOS applications.
* Add some things to config.h for C++ friendliness.
* Import some more GPL code from libntfs into lowntfs.c,
in order to avoid reimplementing it (or copying & pasting,
which would probably make all the glue code GPL.)
* Write an entirely new kernel_interface.cpp, modeled after exfat's
and other newer filesystem drivers. Highlights:
- significant use of C++ RAII objects
- entry_cache support
- file_cache support (thus also read_pages)
- readdir of multiple dirents at once
Most NTFS tickets open at present are related to write support,
and this does not yet have that. It should however be considered
a part of #17165.
Change-Id: I6d5aa53d4d06846b0de5e6ce1431219bf70a6f2c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4679
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It originated on BeOS, and still retains a number of relics of that.
It did not support the file cache, it was rather slow on large disks,
and it had incorrect unlink behavior (delete immediately rather than
on vnode close.) It also is C, not C++.
libntfs-3g has also undergone significant changes in the time since
this driver was written, and it also has a "low level" FUSE module
that we can reuse a lot more code from, so a new driver will be
able to shed a lot of code and use more from upstream directly.
That is coming in the next commits.
Change-Id: Id6f8f8f85076dda92b289ef5a2f1ca6cd484f3e5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4678
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Things seem to still work OK ... insofar as they ever did.
Change-Id: I32ba3c71c27106558092fee636f135f477f1cf36
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4677
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Normally we are only reading or writing from one field in the stat,
and so we do not need to worry about initializing the others. However,
in the case of timestamps, we use only the "tv_sec" field, and so
the "tv_nsec" field was getting passed to filesystem drivers with
bogus data (on x86_64 at least, very large values.)
This went largely unnoticed, despite being used in every Tracker copy
operation, because BFS only uses the lower bits of tv_nsec.
But NTFS and others use the whole field, leading to timestamps
far in the future.
This may fix some of the issues on the bugtracker about timestamp
problems in filesystems other than BFS (and slight inaccuracies in
BFS timestamps on copies, too.)
Change-Id: I5fdbd264fb145af57b7bf2f7b491c6943024811e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4707
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
