In particular: consistent rounding and extreme values.
Before, rounding was something like 'away from 0.999...', which led to
surprising corner cases in which the value was rounded up.
Now, rounding is always 'down'.
This even works for 0xffffffff, and also for 0xffffffffffffffffULL on 64-bit.
This makes error messages more useful during debugging.
Old:
START Running test compare_views
FAIL: ../AK/Tests/TestStringView.cpp:59: EXPECT_EQ(view1, "foobar") failed
New:
START Running test compare_views
FAIL: ../AK/Tests/TestStringView.cpp:59: EXPECT_EQ(view1, "foobar") failed: LHS="foo", RHS="foobar"
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.)
When a resize_aspect_ratio is specified, and window will only be resized
to a multiple of that ratio. When resize_aspect_ratio is set, windows
cannot be tiled.
Any (future) program that includes this header would fail to compile, because the
private symbol 'kind_name' is defined, along with a bunch of code, but unused.
A good way to see this is by #include'ing LibCrypto/ASN1/ASN1.h in an unrelated
.cpp-file, for example Userland/md.cpp.
No other headers seem to have this problem.
The kernel no longer needs sprintf (which might, in theory, overflow),
so we can hide the C++ declaration and make the function uncallable
from within the kernel.
However, libstdc++ still links against it, as libstdc++ uses it for
demangling, from AK::demangle().
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.
Previously, it would just print something with 'FAIL' to stderr which
would be picked up by CTest. However, some code assumes that
ASSERT_NOT_REACHED() doesn't return, for example:
bool foo(int value) {
switch(value) {
case 0:
return true;
case 1:
return false;
default:
ASSERT_NOT_REACHED();
}
// warning: control reaches end of non-void function
}
Thankfully, this hasn't happened in any other code yet, but it happened
while I was trying something out. Using '==' on two ByteBuffers to check
whether they're equal seemed straight-forward, so I ran into the trap.
This seems to be because ByteBuffer implements 'operator bool', and C++
considers bool to be an integer type. Thus, when trying to find a way to
evaluate '==', it attempts integer promotion, which in turn finds 'operator bool'.
This explains why all non-empty buffers seem to be equal, but different from the
empty one. Also, why comparison seems to be implemented.
