Do not mark BPF extern C returns as zeroext

[kevin-valerio]

Fixes #158028

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dingxiangfei2009 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 20 candidates

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[bjorn3]

@bors r+

[rust-bors]

📌 Commit 00da20b has been approved by bjorn3

It is now in the queue for this repository.

[rust-bors]

💔 Test for d33895b failed: CI. Failed job:

• auto - x86_64-gnu-nopt (web logs, enhanced plaintext logs)

[workingjubilee]

It's unclear to me that there is a bug to fix here as the issue at hand rests on the question of what is the actual convention for 16-bit return values, as implemented by C compilers in practice?

[bjorn3]

I looked at the clang source and it seemed like it didn't do any extension of return values. But then again, the code is not that easy to understand.

[workingjubilee]

@kevin-valerio When reporting issues about C interop that have bubbled up from a model, please verify it actually is a problem with gcc or clang if all the declarations are correct on both sides.

If some code that originally, in C, is declared as having a signature like uint32_t func(), and it needs masking when called after being declared in Rust as unsafe extern "C" { fn func() -> u16 }, then the problem is that the declaration is incorrect. That's why we made them unsafe to declare. It is unsound to make the wrong declaration. If they do not set r0 to a value invalid as a u16 when you declare the return is a u16, then the current behavior is equally correct as the post-patch state. The eBPF layer itself of translation to actual execution can also affect these decisions here.

I don't think this patch is particularly awful, but you seem to be submitting quite a lot of things so I'd rather we not take them on good faith alone.

[workingjubilee]

Specifically, "This is definitely a problem, and a rustc developer doesn't have to speculatively read clang source code hoping to figure out what would actually be going on" makes it much easier to accept this (and also future patches where things might be more complicated and less clear that we should simply accept "playing defense" because the cost is admittedly probably low? ...but also I don't really know that it's that low because I know eBPF goes through a translation layer so things can cost more).