Before, we had about these occurrence counts:
COPY: 13 without, 33 with
MOVE: 12 without, 28 with
Clearly, 'with' was the preferred way. However, this introduced double-semicolons
all over the place, and caused some warnings to trigger.
This patch *forces* the usage of a semi-colon when calling the macro,
by removing the semi-colon within the macro. (And thus also gets rid
of the double-semicolon.)
The implementation in LibC did a timestamp->day-of-week conversion
which looks like a valuable thing to have. But we only need it in
time_to_tm, where we already computed year/month/day -- so let's
consolidate on the day_of_week function in DateTime (which is
getting extracted to AK).
The JS tests pointed out that the implementation in DateTime
had an off-by-one in the month when doing the leap year check,
so this change fixes that bug.
mktime() is supposed to fill in tm_wday and tm_yday, and it
it's supposed to canonicalize out-of-range values (that is,
"Jan 31" is turned into "Feb 1").
Instead of making the straightfoward tm_to_time() implementation
more complicated, just make it call time_to_tm() once the timestamp
is computed to break it back down ot (canonical) tm entries.
An overlong group name in /etc/groups would have caused getgrent() to overflow
the global __grdb_entry. Curiously, overflow *within* __grdb_entry seems to have
no detrimental effects.
However, it was possible for a malicious sysadmin(?!) to craft an /etc/group
that overflows outside of the page allocated for __grdb_entry thus crash the
calling process. This affected at least SystemServer and su.
Now, the group name will be simply truncated. For display purposes, this is
fine. In case there is an exceptionally long group, it will not be properly
recognized. Also, a malicious /etc/groups might cause the caller of getgrent()
to become confused, but that is unavoidable.
Before, strftime unintentionally interpreted 0 as 'unlimited'. The specification
of strftime says no such thing.
Now, it properly returns 0 in that case (because the NUL byte doesn't fit).
strdup: Because the length is already known at the time of copying, there is
no need to use strcpy (which has to check every single byte, and thus tends
to be slower than memcpy).
strndup: If 'str' is not NUL-terminated, strndup used to run off into the
adjacent memory region. This can be fixed by using the proper strlen variant:
strnlen.
Year computation has to be based on seconds, not days, in case
t is < 0 but t / __seconds_per_day is 0.
Year computation also has to consider negative timestamps.
With this, days is always positive and <= the number of days in the
year, so base the tm_wday computation directly on the timestamp,
and do it first, before t is modified in the year computation.
In C, % can return a negative number if the left operand is negative,
compensate for that.
Tested via test-js. (Except for tm_wday, since we don't implement
Date.prototype.getUTCDate() yet.)
snprintf is supposed to *always* NUL-terminate its output, so it has to write one
output byte fewer.
And yes, I *did* check all existing usages; this shouldn't break anything.
timegm() is like mktime() in that it converts a struct tm to
a timestamp, but it treats the struct tm as UTC instead of as
local time.
timegm() is nonstandard, but availabe in both Linux and BSD,
and it's a useful function to have.
The SI prefixes "k", "M", "G" mean "10^3", "10^6", "10^9".
The IEC prefixes "Ki", "Mi", "Gi" mean "2^10", "2^20", "2^30".
Let's use the correct name, at least in code.
Only changes the name of the constants, no other behavior change.
This is racy in userspace and non-racy in kernelspace so let's keep
it in kernelspace.
The behavior change where CLOEXEC is preserved when dup2() is called
with (old_fd == new_fd) was good though, let's keep that.
If the space cannot be allocated, the original memory block shall remain
unchanged and the function should return nullptr.
Also add a function attribute and some null checks.
This adds a new header <sys/internals.h>, which provides access to LibC internals.
This is in the interest of type-checking LibC itself, as well as enabling less-hacky
access for uses like LinkDemo.
And, of course, this progresses LibC towards building cleanly with -Wmissing-declarations.
I'm not sure how else to handle this. Curiously, I can't find the string '_start'
anywhere else in the project. Could it be that we haven't NIH'd this yet?
And that we actually rely on magic from the compiler to call _start for us?
This enables a nice warning in case a function becomes dead code.
For example with the unused function malloc_good_size() :^)
I found these places by using -Wmissing-declarations.
The Kernel still shows these issues, which I think are false-positives,
but don't want to touch:
- Libraries/LibC/crt0.cpp:41:5: int _start(int, char**, char**)
Not sure how to handle this.
- Libraries/LibC/cxxabi.cpp:48:5: int __cxa_atexit(AtExitFunction, void*, void*)
- Libraries/LibC/cxxabi.cpp:58:6: void __cxa_finalize(void*)
Not sure how to tell the compiler that the compiler is already using them.
- Libraries/LibC/libcinit.cpp:36:6: void __libc_init()
- Libraries/LibC/libcinit.cpp:55:19: void __stack_chk_fail()
- Libraries/LibC/malloc.cpp:430:6: void __malloc_init()
- Libraries/LibC/stdio.cpp:562:6: void __stdio_init()
These are ninja-imported by other LibC functions.
Maybe we should have some kind of "internals.h" header.
