It doesn't only impact malloc. It's designed to be usable for stack frames instead of stack canaries too. It also impacts usage of the pointers derived from what gets returned by malloc even in an implementation only using it for malloc. It doesn't only impact the malloc memory.
Conversation
None of what I said relies on this being restricted to impacting malloc. You don't need UB in the language to say that stack canaries are a thing.
2
I'm talking about memory tagging as a replacement for stack canaries, not stack canaries. I'm not sure why you're responding about stack canaries. Memory tagging the stack frame makes it so that trying to use pointers to the stack frame to access memory outside it will trap.
1
1
Memory tagging works fine with the spec I'm proposing. So do stack canaries. I'm making the point that the security technologies that you are interested in (and that I'm also interested in) work fine if the language is more strongly specified.
1
Sure, and as I've stated many times in this conversation, I would like for C to be more strongly specified. However, defining something like signed integer overflow as guaranteed to wrap would be a step backwards for implementations that want to make it safer such as trapping.
2
2
But making it traps breaks real C code, so it can't be what the spec says.
Good specs respect their existing clients!
1
Forbidding trapping also breaks widely deployed existing implementations, so you can't do that either per your own rules, sorry.
1
1
We have a case of clients disagreeing. I would put it to a vote. My clients will win it no problem.
1
Oh, right, so you weren't actually being truthful about respecting existing implementations and deployments of the standard. It fits with how you've been arguing the entire time. You are being incredibly dishonest and manipulative along with misrepresenting what I've been saying.
1
No, it's about being realistic about what the overwhelming majority of C programs expect. Just because a minority compiles with weird behavior-altering flags doesn't mean that gets to be the default.
1
Deployments of C without any features like _FORTIFY_SOURCE incompatible with how you want the C standard redefined are not the minority. It's also not at all weird to provide safety features based on what the standard doesn't permit, like catching memory unsafe accesses.
If anything is weird, it's someone demanding that it shouldn't be permitted. It almost comes across as trolling to demand features like type-based CFI and memory safety checks currently fully compliant with the standards become forbidden instead. Never seen someone argue that...
1
Not permitting it in the spec is not the same thing as not permitting it. If the spec says that the behavior is X, it doesn't mean that someone can't make something where the behavior is Y. They just have to be clear about the fact that they aren't obeying published behavior.