Hacker News Reader

Comment by Animats | Hacker News Reader

From the technical paper:

    Checked C adds new types to C:
    • ptr<T>, the checked pointer to singleton type,
    • array_ptr<T>, the checked pointer to array type,
    • T checked[N], the checked array type,

Many people have been down that road. GCC had "fat pointers" for subscript checking years ago.[1] That never caught on. Walter Bright had a proposal.[2] I had a proposal. Microsoft had "Managed C++". It's technically possible, but retrofitting old code rarely happens.

[1] http://williambader.com/bounds/example.html [2] https://news.ycombinator.com/item?id=8509155

View on HN

It only works when companies take the "my way or the high way" approach.

Hence why Microsoft went C++ and .NET Native, keeping C compatibility just as far as ANSI C++ requires it. And support C++ kernel code since Windows 8.

Why the NDK is such a pain to use on Android, with a very tiny API surface.

Why all Objective-C improvements are now only related to improve interoperability with Swift.

So maybe if Microsoft decides to also force Checked C on Windows, it might eventually work.

10-15 years ago, Microsoft had the clout to do that. They no longer do.

They still do, just in HN bubble people think they don't.

Azure is a money printing machine, the "Year of Desktop Linux" will never happen, hybrid tablets/laptops with Windows are being bought instead of Android ones, IoT devices for healthcare or ticketing machines run on Windows, on the enterprise Linux mostly matters on the server room, they own PC/XBox gaming.

So just like Apple and Google, they can do whatever they feel like it, because non-technical consumers aren't going to suddenly start buying alternative systems, just because devs don't like Apple, Google and Microsoft roadmaps regarding which programming languages one is allowed to use on their systems.

> if Microsoft decides to also force Checked C on Windows

how does this happen without diverging from the history of backwards compatibility?

> It's technically possible, but retrofitting old code rarely happens.

Yeah. A more realistic solution might be auto-translation of existing code. Here[1] is an example that replaces declarations of arrays, and pointers used as array iterators, with macros that enable the code to be compiled as either unsafe C code or "safe" C++ code (bounds checked and iterator use-after-free safe).

Determining in general whether or not a pointer is being used as an array iterator, or a pointer to an array is not trivial. It sometimes has to be deduced from context. Which may be why it doesn't seem to have been done already?

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Reply on news.ycombinator.com