[PATCH] D86993: Document Clang's expectations of the C standard library.

Wed Jul 5 11:40:01 PDT 2023

nikic added a comment.

In D86993#4474392 <https://reviews.llvm.org/D86993#4474392>, @rjmccall wrote:

> In D86993#4474267 <https://reviews.llvm.org/D86993#4474267>, @RalfJung wrote:
>
>> The first point is important for LLVM's own memcpy/memmove intrinsics, which are documented as NOPs on size 0 (and e.g. Rust relies on that).
>
> Right, I understand that these assumptions come directly from the stronger semantics offered by the LLVM intrinsics.  The C committee is not going to find that compelling, though — we don't get to default-win arguments just because we've defined an IR with stronger semantics than necessary.  They are going to want to see arguments about why it's valuable for the C library to have these stronger semantics, which for us means talking about code patterns in user programs that take advantage of those stronger semantics and the benefits they see from that.

I think the argument for this one is pretty clear:

- Lower code size: No need to add an explicit `n != 0` check.
- Better performance: If the `n == 0` case is rare, you don't have to do that redundant check.
- Better security: You are less likely to cause UB by forgetting a `n != 0` check in place that needs it.

When I made an old code base ubsan compliant some time ago, adding these checks certainly felt like the one case where fixing the sanitizer diagnostics made the code objectively worse on all possible metrics. Take into account that the requirement for nonnull pointers for `n != 0` does not allow any useful optimization of the memcpy implementation, and this seems like a no-brainer.

In D86993#4474549 <https://reviews.llvm.org/D86993#4474549>, @RalfJung wrote:

> I was told that "glibc explicitly only marks memcpy arguments as nonnull for external use of headers (i.e. the nonnull assumptions are disabled when compiling the implementation)"... okay now re-reading this, that's a statement about glibc, not GCC.

Right. glibc only adds nonnull annotations to declarations when included by users of glibc. The implementation is compiled without any such assumptions (though of course, usually you get an assembly implementation anyway). Musl doesn't annotate nonnull either way.

> Anyway this is outside my expertise. I will try to add Nikita here who said "GCC also requires passing equal pointer to memcpy to be legal".

GCC uses equal pointer memcpy in pretty much exactly the same cases as Clang does: Aggregate assignments.

> I continue to think it's a mistake for us to document that Clang will not work with a conforming C standard library implementation unless we're filing issues with WG14 to alert them to the reasons why. If there's a DR filed with the committee, that gives us something to point our users to as justification. Otherwise, our users will correctly put these bugs at our feet.

As you are involved with WG14, can you please take care of that? I couldn't even find out how one is supposed to file a DR.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993