aaron.ballman added a comment.
In D123544#3446265 <https://reviews.llvm.org/D123544#3446265>, @void wrote:
> Could you explain a bit more why it's not considered conforming behavior in
> C? The entire feature is definitely unusual and introduces some caveats (the
> structure initialization being just one of them).
Given:
typedef void (*func_ptr)(void);
struct S {
func_ptr f1, f2, f3;
};
void func(void);
struct S s = {func, 0, func};
C requires that s.f1 and s.f3 point to func and s.f2 is a null pointer, but if
you automatically randomize the layout of that structure as in this patch, this
strictly conforming code will break.
However, I had forgotten that the base feature *requires* the user to pass a
randomization seed via a flag in addition to requiring the attribute (thank you
for bringing that back to my attention). Because this feature requires a
feature flag to enable it, this behavior *is* a conforming extension (the user
has to take an action to get the new behavior). That said, I'm still not
convinced we want to do this automagically for users -- it's *really* easy for
that flag to be set in a makefile somewhere and the user has no idea that their
(non-designated) initialization is now a security vulnerability. If we had
error diagnostics when the user is about to shoot their foot off, I'd be more
comfortable with the automatic hardening behavior.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D123544/new/
https://reviews.llvm.org/D123544
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
