Language extension for maintenance of legacy application sounds a little bullsh1t to me.
0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application.
1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors/exceptions (like overflows) would need handling and changes in logic. It could only deny read/write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).
One use case I see is to add an extension (like GCC's for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.
I'm sensing a huge incomprehension in a great amount of posts. The key is to know the purpouse of tools. C is a "close-to-the-metal" type language. You can control a low-level things, execution time, "number of hops" when writing data, etc. If you want a friendly language with "no segfaults, no memory leaks" then go higher level (which in many cases is a better choice, i.e. a GUI desktop application with no performance constraint). If you have a problems wrigint in C then you simply still can't C and using the wrong tool for the task.
"But C? C's dead. It's the language for old programmers who want to debate section A.6.2 paragraph 4 of the undefined behavior of pointers"
Someone has to build the low-level stuff. Dear boys in too-tight pants and a hippie mustache: your high-level things and gluten-free snacks does not grow on trees.
Capturing the CPU instructions by a side-channel is indeed possible but the "real-life, working" use of the method described here is questionable for me. CPU in modern phones runs above 1GHz. USB sound card they're using provides max 192kHz which allows max 96kHz signal. 4 orders of magnitude less. There's also a lot of noise from different circuitry (GPU, display, wireless comm.) and laptop's noise as well which will obfuscate the signal.
I would recommend low power nRF51 chips. It's a Cortex M0 with integrated 2,4GHz radio. You can use is for Bluetooth Low Energy and communicate with other chips / smartphones / etc (manufacturer provides a BLE stack) or your own simple protocol. There are some modules below $10, but those would require additional USB chip (like ft232 or $2 pl2303 / ch341 module).
If you need a long distance (like 1km) communication then you need a "larger" radio which works in ISM band. For the cheapest solution I'd go with mass produced devices - two WiFi APs with 2 directional antennas + some custom boards ob both sides or APs with open firmware like openWRT.
0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application. 1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors/exceptions (like overflows) would need handling and changes in logic. It could only deny read/write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).
One use case I see is to add an extension (like GCC's for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.