Hacker News Reader

Hacker News

Comment by WalterBright | Hacker News Reader

Parent Full thread

WalterBright

In my experience with language design, a little bit of syntactic sugar can have transformative results.

C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

View on HN

> In my experience with language design, a little bit of syntactic sugar can have transformative results.

I agree 100%. This also reminds me of this article:

https://nibblestew.blogspot.com/2020/03/its-not-what-program...

HN discussion: https://news.ycombinator.com/item?id=22696229

I totally agree that C shepherds you into pointers. I also think C shepherds you into writing everything from scratch. Most of all I think it's a self-perpetuating cycle of "there's no system for X (e.g. sized arrays, packaging system, classes) so everyone makes their own, and now all other code feels slightly incompatible with all other code."

C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been propagated through the compiler and assembler to the linker, which would then check for compatibility.

In some ways it would have worked much better. Header files can easily be wrong. The object files being linked are what really matter.

So, suppose we decided to implement this today, on a GNU toolchain. At the call site, we'd determine the parameter types based on the conventional promotions. This info gets put into the assembly output with an assembler directive. The assembler sees that, then encodes it in an ELF section. It might get a new section called ".calltype" or it is an extension to the symbol table or it involves DWARF. Similar information is produced for the function body. The linker comes along, compares the two, and accepts or rejects as appropriate.

This would require storing type information in a symbol, would it not? Either via mangling or some other method.

Yes. I proposed a method without mangling, but I suppose there isn't any reason why C couldn't use mangled names.

It also isn't a requirement that C++ use mangled names. Other ways of carrying the type information are possible. I like the idea of a reference to DWARF debug info, which C++ is already using to support stack unwinding for exceptions.

> It also isn't a requirement that C++ use mangled names.

Overloading requires the type information to be part of the symbol "name" (ie, whatever is used for symbol lookup and linking) wether that is a mangled string or more complex data structure.

> In my experience with language design, a little bit of syntactic sugar can have transformative results.

Promises/async functions in JS and C# do absolutely nothing that you couldn't do without them. But they've had a structural effect on the average developer's ability to write scalable code.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

x86 has a BOUND instruction which generates an exception if an index is out of bounds. It didn't make it into x64.

This is likely coming in ARM soon. (And I'm hopeful it's not even soon™, or "it came but nobody used it" as has happened on x86.)

CHERI is an attempt. DARPA paid to have it for RISC-V and ARMv8. It was originally for MIPS.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

It is fundamentally like the 80286 segments, but with all sorts of usability troubles solved. The 80286 segments were impractical because there were a small number available and because the OS couldn't safely hand over direct control. Every little segment adjustment required calling the OS.

Going forward Android will require hardware metadata extensions on ARM devices, as of Android 11.

You bring this up often and I ask you to modify your wording about every time I see it. Android will not require these extensions, no hardware ships with it yet. Android says they will support it.

And I give you the official wording of Google every time.

> Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem. Based on the current data points, MTE provides tremendous benefits at acceptable performance costs. We are considering MTE as a possible foundational requirement for certain tiers of Android devices.

https://security.googleblog.com/2019/08/adopting-arm-memory-...

> Starting in Android 11, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support.

>....

> This will disable the Pointer Tagging feature for your application. Please note that this does not address the underlying code health problem. This escape hatch will disappear in future versions of Android, because issues of this nature will be incompatible with MTE

https://source.android.com/devices/tech/debug/tagged-pointer...

So unless you have other official feedback from Google management, I will keep repeating myself.

I am not sure if I have made myself clear, because I have no issues with the Google documents on this and I believe they are very clear: this feature is optional! Optional optional optional, only on hardware that supports it will Google implement these things because they literally cannot use it otherwise. Your wording has always implied that this is a requirement to run Android 11 and it is not, and that is what I am asking you to change. Like, what’s wrong with being accurate and saying “Google is implementing support for this in Android 11”? “This feature may be used to classify Android devices”?

Reply on news.ycombinator.com