- `header/row_of_values`, same `header/row`, more verbose name
- `aligned_header/row_of_values`, set alignment for an entire row
- `header/row_of_aligned_values`, set alignment per value
I am uncertain why this works, but it does. Previously, `rtti_test` was
failing due to non-zero data appearing in the `l_buggy` `Buggy_Struct`.
The issue was caused by calling `runtime.default_random_generator` with
a pointer to the state, somehow. The pointer could be on the stack or in
the heap; it did not matter.
I found two workarounds.
- One is to move the RNG setup behind the call to `free_all`.
- The other is to construct the random generator manually.
Despite my digging and testing, I could find no reason as to why this
works or what the fundamental issue was to begin with. If anyone comes
upon this in the future with direct access to a Windows machine, I
recommend stepping through the program with a debugger to investigate
more deeply into why this happens.
It's possible for the return string to be longer than 128 characters
these days, so I've increased it to 1024, same as the other BSDs.
SYSCTL was otherwise erring out due to lack of buffer space.
This is a BSD-style syscall that checks for a high Carry Flag as the
error state. If the CF is high, the boolean return value is false, and
if it is low (no errors) then the boolean return value is true.
It was using the generic UNIX `fstat` implemented in Odin, which is more
than what is needed here.
This also avoids the issue of needing a proper
`absolute_path_from_handle` implementation for it to work without error.
`ODIN_VERSION_HASH` is the `git` SHA hash of the commit the Odin
compiler was built with.
`ODIN_MICROARCH_STRING` is the string passed to `-microarch` when
the program was built.
`ODIN_OPTIMIZATION_MODE` is an enum value of which optimization mode was
used to build the program.
The requirement for at least 2 indices has been sourced from
`lb_addr_swizzle` in `llvm_backend_general.cpp`, where there is an
assert to ensure the swizzle_count is `1 < n <= 4`.
To clarify, `parse_f64` will indeed take `infi` to mean `+Inf` and
return that as the value, but it will not return `ok = true`. It treats
it as `inf` followed by any other trailing character.
`parse_f64_prefix` is the lenient one which will return true so long as
it finds some meaningful value.
The full "infinity" strings were expected to be partial consumes, but
this is not the case. That has been fixed and the relevant extra tests
from that file have been added to this test suite.
Fixes#2670
Tested on FreeBSD 14.0 and NetBSD 10.0
OpenBSD is untested, but link names were sourced from:
https://github.com/openbsd/src/blob/master/include/stdio.h
According to this, OpenBSD shares the same layout as NetBSD.
FreeBSD has the same as Darwin in this regard.
I was encountering bounds-check error messages being overwritten during
a test, if the test failed for another reason and sent a log message.
The original intent of having this check inside of the above `if` block
was that if a test sent an error message, then it was assumed an
overwrite would be safe, but it's completely possible for a test to fail
for a legitimate reason, then do an unrelated bounds check somewhere
else that would be buried under the animation.
This change will make sure that, no matter what, the progress display
will not trigger a clear if a signal was raised. There's still no
guarantee that bounds-check messages will be printed properly, and it's
best to redirect STDERR.
The only way that can be fixed is if they get a similar hook to
`context.assertion_failure_proc`.
Feoramund