Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

The Linux kernel chooses to use a superset of standard C. It doesn't ignore the rules that it isn't disabling via those switches but rather is actively tested with ASan and UBSan, with people working to address the cases that are not permitted, usually by fixing the kernel bugs.

Replying to

You’re still hung up on a false choice between a well defined spec and instrumentation/tools that alter behavior while giving you something good in return. A defined behavior for C wouldn’t stop those tools from existing.

Replying to

The defined behavior can be trapping, which makes more sense in 2019 with software safety / security / robustness as such important issues. Hardware can and is being designed to make it efficient to catch these issues too. It can also just permit safety without using 'undefined'.

Replying to

That definition would make lots of real systems stop working, so that’s clearly the wrong direction for the spec. A good spec respects its customers.

This Tweet was deleted by the Tweet author. Learn more

Replying to

It does exist. Existing hardware has lots of safety features in hardware that are being actively used to catch these kinds of issues. More of those features are shipping over time. Intel CET and ARM MTE (which is like the existing SPARC ADI) are major examples of new features.

Replying to

There is nothing about Intel CET that requires UB from the language; as I said, the compiler/spec don't have to reveal how function calls work. In my C spec, a load/store would be said to either load/store or trap, depending on how the runtime/CPU did things. So ARM MTE is OK.

Replying to

So, it's okay to trap when indexing from one object to another and then dereferencing, or when constructing a non-derived pointer to an object in any other way and dereferencing it? That's what memory tagging will cause, since it aims to have the tags not match in those cases.

Replying to

No. Language says that there is no such thing as an object - it's all integer-addressed bytes. Language further acknowledges that virtual memory and trap-on-access exists. It's simple: you just write a spec of reality instead of playing silly games.

Replying to

Okay, so you don't want SPARC ADI and ARM MTE to be used as designed in a standards compliant C implementation which the current C standard permits. It's not playing games. Having at least a weak approximation of memory safety like tagging and various other features is important.

9:53 PM · Apr 16, 2019Twitter Web Client

Replying to

I just made the opposite point: that MTE works fine if the language is spec'd the way I'm proposing. It allows them to be used as designed by removing the notion of malloc from the language.

Replying to

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.

Show replies