PanTao2 wrote: Yes, that's a real difference. f() is protected by clang-cl today, and cl.exe 19.44 does not protect it. After this patch clang-cl wouldn't protect it either.
The gap is specific to scalars and small aggregates passed by pointer, for example read(fd, &x, len) with len > sizeof(int). An array, or an aggregate over 8 bytes with no pointers, is protected by both. I'm not aware of a published analysis of how much real-world risk this adds, but I don't want to claim there is none. The patch isn't only a reduction in protection. On my corpus of 787 functions, today's clang-cl agrees with cl.exe 19.44 on 601 and this patch on 761. The functions cl.exe protects but clang-cl doesn't go from 13 to 1. That one is an inlining artifact. clang-cl can't both match MSVC and avoid MSVC's gaps. Anyone who wants the wider protection has two options: - /clang:-fstack-protector-strong restores the previous behaviour. - __declspec(strict_gs_check), MSVC's own opt-in for stricter checking, now selects the broader heuristic per function. I think matching MSVC is the right default, because /GS users expect MSVC's behaviour, and the release notes will say plainly what changed. https://github.com/llvm/llvm-project/pull/225626 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
