If SO_TIMESTAMP is unsupported, we won't be able to determine
kernelspace-to-userspace latency. But other than that, things should
still build and work.
(It's a separate question of what "kernelspace-to-userspace latency"
even means on a microkernel system, where the network card drivers, the
network stack, and ntpquery(1) are all running as userspace programs.)
Also, don't fail completely if settting receive timeout fails.
Absolute paths in man page links such as
```
[some link](/foo/bar)
```
Were being interpreted as relative paths when rendered in HTML. This
issue was observed in #20889 and #20041.
The fix is to make sure we don't leave any absolute paths when parsing
links. Instead we check if a directory is absolute (by checking for `/`)
and add `file://` accordingly. This turns the above link into:
```
[some link](file:///foo/bar)
```
Which does get interpreted correctly when rendered as HTML.
- fixes#20889
- fixes#20041
Before this patch, opening the Help application would raise an error.
Now all the pictures in the man pages render correctly.
There are a bunch of tests that check for time_t handling 64-bit values
properly. This makes sense, but also obviously doesn't work when time_t
is 32-bit, and causes compile-time errors. Compile these tests out in
that case.
Since there's no straightforward way to check sizeof(time_t) inside the
proprocessor, only do this when glibc's __TIMESIZE is defined.
This is defined when we're compiling against the GNU C Library, whether
on Linux or on other kernels that glibc works on. More AK_LIBC_xxxx
definitions could be potentially added in the future.
Also add AK_LIBC_GLIBC_PREREQ(), which checks for a specific glibc
version.
Previously if the IDL was something like:
```
constructor(optional DOMString data = "");
```
We were generating code that would be passing through to the constructor
an Optional<String> - even though for this situation it is not possible
for it to be null.
Instead, if we know if there is a default value that is non-null and the
type is not nullish, just generate the cpp code as a String.
This change allows IDL interfaces to be compiled using new AK String
which have a attribute in the interface that may return null.
Without this change we would run into a compile error from code such as
the following example:
```
auto retval = impl->deprecated_attribute(HTML::AttributeNames::ref);
if (!retval.has_value()) {
return JS::js_null();
}
return JS::PrimitiveString::create(vm, retval.release_value());
```
As `deprecated_attribute` returns a `DeprecatedString` instead of an
`Optional<String>`. Fix that by using the non-deprecated attribute
implementation, and falling back to the empty string for where we cannot
return null.
Also add a test here to cover a regression I almost introduced here
which was not previously covered by our test suite.
Ideally, all of this should actually just be calling
Element::get_attribute_value, but I'm not entirely sure at this stage
what the behavioral change would be to test for here. Since this
implementation preserves the previous behavior, stick with it, and add a
FIXME for now.
This should allow us to add a Element::attribute which returns an
Optional<String>. Eventually all callers should be ported to switch from
the DeprecatedString version, but in the meantime, this should allow us
to port some more IDL interfaces away from DeprecatedString.
