And move canonicalized_path() to a static method on LexicalPath.
This is to make it clear that FileSystemPath/canonicalized_path() only
perform *lexical* canonicalization.
It's not enough to send ourselves a SIGABRT, as it may be ignored or handled
differently. We really, really want abort() to never return, as that will mess
up the assumptions of the calling code big time. So, if raise(SIGABRT) returns,
kill ourselves with SIGKILL, and if that somehow returns too, call _exit().
An alternative approach, which glibc apparently follows, is to reset SIGABRT
disposition to its default value and then send SIGABRT to yourself a second
time. That would also work, but I believe SIGKILL + _exit() to be a simpler
approach that is less likely to break in extremely weird situations.
Note that this only guarantees that abort() never returns, not that the process
actually gets killed. It's still possible to install a SIGABRT handler that
simply never returns (such as by longjmp'ing out, endlessly looping, or exec'ing
another image). That is a legitimate use case we want to support; at the same
time most software doesn't use that functionality and would benefit from hard
guarantees that abort() terminates the program. The following commit is going to
introduce means for ensuring SIGABRT handler is never reset to something
unexpected.
While the compiler provides __SIZE_TYPE__ for declaring size_t,
there's unfortunately no __SSIZE_TYPE__ for ssize_t.
However, we can trick the preprocessor into doing what we want anyway
by doing "#define unsigned signed" before using __SIZE_TYPE__ again.
This file is required for building the git port.
It was already added before and then removed again when the CI script
for license header checks was added as it seemed irrelevant.
When we flush a FILE, we behave differently depending on whether we reading from
the file or writing to it:
* If we're writing, we actually write out the buffered data.
* If we're reading, we just drop the buffered (read ahead) data.
After flushing, there should be no additional buffered state stdio keeps about a
FILE, compared to what is true about the underlying file. This includes file
position (offset). When flushing writes, this is taken care of automatically,
but dropping the buffer is not enough to achieve that when reading. This commit
fixes that by seeking back explicitly in that case.
One way the problem manifested itself was upon fseek(SEEK_CUR) calls, as the
position of the underlying file was oftentimes different to the logical position
of the FILE. Since FILE::seek() already calls FILE::flush() prior to actually
modifying the position, fixing FILE::flush() to sync the positions is enough to
fix that issue.
Make sure that userspace is always referencing "system" headers in a way
that would build on target :). This means removing the explicit
include_directories of Libraries/LibC in favor of having it export its
headers as SYSTEM. Also remove a redundant include_directories of
Libraries in the 'serenity build' part of the build script. It's already
set at the top.
This causes issues for the Kernel, and for crt0.o. These special cases
are handled individually.
This is __cxa_guard_acquire, __cxa_guard_release, and __cxa_guard_abort.
We put these symbols in a 'fake' libstdc++ to trick gcc into thinking it
has libstdc++. These symbols are necessary for C++ programs and not C
programs, so, seems file. There's no way to tell gcc that, for example,
the standard lib it should use is libc++ or libc. So, this is what we
have for now.
When threaded code enters a block that is trying to call the constructor
for a block-scope static, the compiler will emit calls to these methods
to handle the "call_once" nature of block-scope statics.
The compiler creates a 64-bit guard variable, which it checks the first
byte of to determine if the variable should be intialized or not.
If the compiler-generated code reads that byte as a 0, it will call
__cxa_guard_acquire to try and be the thread to call the constructor for
the static variable. If the first byte is 1, it will assume that the
variable's constructor was called, and go on to access it.
__cxa_guard_acquire uses one of the 7 implementation defined bytes of
the guard variable as an atomic 8 bit variable. To control a state
machine that lets each entering thread know if they gained
'initialization rights', someone is working on the varaible, someone is
working on the varaible and there's at least one thread waiting for it
to be intialized, or if the variable was initialized and it's time to
access it. We only store a 1 to the byte the compiler looks at in
__cxa_guard_release, and use a futex to handle waiting.
This allows operator new and operator delete to be available to anyone
that links -lc (everyone) rather than just people that include
kmalloc.h (almost no one).
This was supposed to be the foundation for some kind of pre-kernel
environment, but nobody is working on it right now, so let's move
everything back into the kernel and remove all the confusion.
We stopped using gettimeofday() in Core::EventLoop a while back,
in favor of clock_gettime() for monotonic time.
Maintaining an optimization for a syscall we're not using doesn't make
a lot of sense, so let's go back to the old-style sys$gettimeofday().
This patch makes strto{u,}l{l,}() behave more to-spec about endptr.
"If endptr is not NULL, strtoull stores the address of the first invalid
character in *endptr."
This fixes the behavior for several inputs:
- '-0' (shouldn't work but was accepted)
- '+3' (shouldn't work but was accepted)
- '13835058055282163712' (should work but returned 9223372036854775807 with errno=ERANGE)
This strtod implementation is not perfectly accurate, as evidenced by the test
(accuracy_strtod.cpp), but it is sufficiently close (up to 8 eps).
The main sources of inaccuracy are:
- Highly repeated division/multiplication by 'base'
(Each operation brings a multiplicative error of 1+2^-53.)
- Loss during the initial conversion from long long to double (most prominently,
69294956446009195 should first be rounded to 69294956446009200 and then
converted to 69294956446009200.0 and then divided by ten, yielding
6929495644600920.0. Currently, it converts first to double, can't represent
69294956446009195.0, and instead represents 69294956446009190, which
eventually yields 6929495644600919.0. Close, but technically wrong.)
I believe that these issues can be fixed by rewriting the part at and after
double value = digits.number();
and that the loss before that is acceptable.
Specifically, losing the exact exponent on overflow is obviously fine.
The only other loss occurs when the significant digits overflow a 'long long'.
But these store 64(-7ish) bits, and the mantissa of a double only stores 52 bits.
With a bit more thinking, one could probably get the error down to 1 or 2 eps.
(But not better.)
Fixes#1979.
In f4302b58fb, the kernel-side syscalls (e.g Process::sys$getsockname)
were updated to use SC_get{sock,peer}name_params, but the libc
functions were not updated.
This commit implements the getprotoent() family of functions, including
getprotoent()
getprotobyname()
getprotobynumber()
setprotoent()
endprotoent()
This implementation is very similar to the getservent family of functions,
which is what led to the discovery of a bug in the process of reading the aliases.
The ByteBuffer for the alias strings didn't include a null terminating character,
this was fixed for both the protoent and servent family of functions by appending a
null character to the end of them before adding them to the alias lists.
fix all requested changes including:
- remove explicit vector initialization
- change keep_service_file_open to boolean
- closing service file on seek error
- change C level char allocation to use ByteBuffer instead
- simplified getservby* loops to a single loop
- change fill_getserv_buffers return to early-return style
