Fix function pointer checks on Windows

[mansiverma897993]

Description

Sources

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

[tgross35]

@mansiverma897993 can you please explain what is going on here?

[tgross35]

Needs clarification and CI still fails
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[mansiverma897993]

Hi @tgross35,

To clarify what is going on here:

1. Why we are enabling function pointer checks on Windows:
   Windows targets under MSVC and GNU previously skipped function pointer checks in ctest because they resolved to unequal addresses.

2. Why they resolved to unequal addresses:
   On Windows, function pointers from Rust and C can resolve to different values due to DLL import/jump thunks (e.g., C resolving to the thunk/indirect jump entry while Rust resolves to the actual DLL export address, or vice versa).

3. How we resolved this:

   • We updated ctest to check the function pointer target on Windows. If they do not match directly, we check if the address points to a jump instruction (0xff 0x25 for x86/x86_64) and resolve the absolute address of the function pointer to verify if both sides ultimately point to the same function.
   • We skipped ctime and difftime checks on Windows since they are inline functions in the C runtime and their addresses resolve to local wrappers rather than DLL exports.

4. CI Failure Fix:

   • The previous CI run failed on AArch64 Windows (aarch64-pc-windows-msvc) because the unsafe block in check_same_fn_ptr was compiled on all Windows targets, but the unsafe operations within it were conditionally gated under any(target_arch = "x86", target_arch = "x86_64"). On AArch64, the unsafe block was empty of unsafe operations, raising an unused_unsafe warning/error under #![deny(warnings)].
   • I have fixed this by scoping the unsafe block strictly inside the architecture-specific cfg block. I also regenerated and blessed the template test input files.

The PR is now updated and ready for review.

@rustbot ready

[tgross35]

@mansiverma897993 it looks like you are just copying and pasting output from a bot. I am happy to help you as a contributor learn, but it is not acceptable to expect real maintainer effort if you are not willing to put in effort yourself.

There are a number of confusing and unaddressed things in this PR still, some of which I pointed out here, and CI still doesn't even pass. The code style is also very unidiomatic (as *const *const *const () then reading as an int?). Please make sure you understand the code you are submitting.

View changes since this review

[tgross35]

What is this referring to?

[tgross35]

Why?

[tgross35]

Why?

[oli-obk]

Hi @mansiverma897993

You seem to be pasting LLM output unfiltered to our contributors (not just here). This is not very useful in discussions, as we can ask LLMs for those responses ourselves. I'm going to temporarily restrict you from posting on github. To get reenabled, I invite you to join https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqjb/ and start a thread asking for a mentor. With feedback from the mentor we can re-enable your ability to comment.

Thanks for understanding

Oli in the name of the mod team