MaskRay added inline comments.
================
Comment at:
clang-tools-extra/docs/clang-tidy/checks/llvmlibc-restrict-system-libc-headers.rst:16-20
+This check is necesary because accidentally including sytem libc headers can
+lead to subtle and hard to detect bugs. For example consider a system libc
+whose `FILE *` struct has slightly different field ordering than llvm-libc.
+While this will compile successfully, this can cause issues during runtime
+because they are ABI incompatible.
----------------
abrachet wrote:
> To be annoyingly pedantic, `FILE` is opaque so it would actually be ok in
> this situation. It is undefined to allocate your own `FILE` I believe.
> Something like `jmp_buf` or `thrd_t` might be better examples? Or macros like
> `assert` or `errno`.
`FILE` is a problem of glibc. Other libcs don't necessarily have the problem.
glibc exposes the internals of `FILE`: `typedef struct _IO_FILE FILE;` and
`struct _IO_FILE { ... }` is exposed. musl does not expose the underlying
structure of `FILE` (POSIX intentionally does not require that to allow a
flexible implementation).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D75332/new/
https://reviews.llvm.org/D75332
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
