https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I don't see how that would help much. You still wouldn't know if the recvmsg or sendmsg that is being called by whatever library and is interposed by libasan etc. is the one with 64-bit msg_iovlen, msg_controllen or cmsg_len, or 32-bit one. E.g. in write_msghdr used by recvmsg wrapper, there is: if (msg->msg_iov && msg->msg_iovlen) COMMON_INTERCEPTOR_WRITE_RANGE(ctx, msg->msg_iov, sizeof(*msg->msg_iov) * msg->msg_iovlen); write_iovec(ctx, msg->msg_iov, msg->msg_iovlen, maxlen); The broken change committed to llvm repo makes this a static choice - if you compile libsanitizer against glibc older than 2.24, you assume msg_iovlen must be always 64-bit, even if you e.g. at runtime link against glibc 2.24 and run a program that uses recvmsg@@GLIBC_2.24. If you compile libsanitizer against glibc 2.24+, you assume msg_iovlen must be always 32-bit, even if the app calls recvmsg@GLIBC_2.2.5. Not sure what dlsym actually gives you in that case, I think recvmsg@@GLIBC_2.24, but it would need to be verified. What we could do is just assume people don't really use > 2G values in these cases, and just use (int) msg->msg_iovlen instead of msg->msg_iovlen (for Linux only). Similarly for the other two fields, and perhaps keep the structures as is and just make the size and offset checks for these fields accept all the expected variants (i.e. also the case where the glibc headers have the field half the size and for big endian also at a different offset (difference of half the size). For e.g. asan, this would just mean that programs linked against glibc < 2.24 that use > 2GB msg_iovlen and overwrite through that some buffer wouldn't be detected, I think that is sufficiently rare that it might be acceptable. Over time more and more programs/libraries will be rebuilt against glibc >= 2.24 and the problem will go away there.