fix test_new_from_file_crafted_executable for m1

[apfitzge]

Problem

Test fails on m1 mac's w/ current rust compiler.

Summary of Changes

Assert that sanitize_executable fails (what we really care about).
Remove the check that *executable_bool == FALSE, which changes based on compilers.

Fixes #

[apfitzge]

Wasn't sure if this issue was due to the m1 architecture itself or the compiler. To test, I wrote a simple c++ program:

#include <iostream>

int main()
{
    bool value = false;
    bool &r = value;
    (*(uint8_t *)&value) = 254;
    if (r == false)
    {
        std::cout << "womp\n";
    }

    return 0;
}

Compiling with clang led to a failure (see womp).
Compiling with gnu led to a success (no womp).
This indicates that it's compiler dependent, rather than an architectural difference. So I elected to change the test, rather than making it configured based on architecture.

[codecov]

Codecov Report

Merging #26009 (cc53b85) into master (8caced6) will decrease coverage by 0.1%.
The diff coverage is 77.5%.

@@            Coverage Diff            @@
##           master   #26009     +/-   ##
=========================================
- Coverage    82.1%    82.0%   -0.2%     
=========================================
  Files         628      631      +3     
  Lines      171471   172920   +1449     
=========================================
+ Hits       140878   141874    +996     
- Misses      30593    31046    +453     

[bw-solana]

lgtm

[ryoqun]

could you restore this with #[cfg(!m1)]?

the intent isn't clear but this test is checking the existence of undefined behavior around bool inside rustc (or llvm): https://doc.rust-lang.org/reference/types/boolean.html:

An object with the boolean type has a size and alignment of 1 each. The value false has the bit pattern 0x00 and the value true has the bit pattern 0x01. It is undefined behavior for an object with the boolean type to have any other bit pattern.

as you know, we're not relying on the UB (bit pattern other than 0x00 and 0x01 for bool) in any production code. however, this assertion is needed to validate that this test is still exposing the UB to make sure we're not relaying on it accidentally. So, if possible, i want to the test to check the existence of UB at least for x64.

any ad-hoc cfg should be fine as long as our CI is happy.

[apfitzge]

Gotcha, re-added the if/panic, but disabled it for aarch64.

[ryoqun]

👍

my memory is vague. but i think i tried to add this assertion, but i couldn't because the ub assertion below stopped working correctly back then. (welcome to UB land. lol)

if today's build toolchain doesn't negatively affect the UB detection code, please leave to assert! here.

[apfitzge]

^passing CI with the assert left there.

Pull request has been modified.

[ryoqun]

@apfitzge lgtm!