An iOS zero-click radio proximity exploit odyssey

Re:An iOS zero-click radio proximity exploit odyssey by Animats on Tuesday December 01, 2020 @06:37PM (#25271524)

I had that argument with the C standards people a decade ago. [1] Consensus was that it would work technically but not politically. The C++ people are too deep into templates to ever get out.

The basic trick for backwards compatibility is that all arrays have sizes, but you get to specify the expression which represents the size and associate it with the array. So you don't need array descriptors and can keep many existing representations.

Also, if you have slices, you rarely need pointer arithmetic. Slices are pointer arithmetic with sane semantics.

I'm tired of seeing decade after decade of C/C++ buffer overflows. It speaks badly of software engineering as a profession.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by gfxgirl on Wednesday December 02, 2020 @02:42AM (#25274079)

Or you could be like Jonathan Blow who claims he never has any memory bug issues and so it's not a problem worth solving in his JAI language.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by Gibbon1 on Tuesday December 01, 2020 @10:56PM (#25273087)

The political aspect is why I suggest the solution is to just up and fire all those guys. More realistically Microsoft, Apple and Linus could just force the issue. Gets added to Visual C/C++, LLVM, and Gnu C as an extention. And then start polluting code bases and API's with it.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by pjmlp on Wednesday December 02, 2020 @06:02AM (#25275312)

Microsoft is already kind of doing it, if you compile in debug mode, you get bounds checking in all STL types, and you can enable them in release builds as well.

But yeah, it only works if you use those types.

There are other divisions pushing for .NET and Rust systems code in Windows, but the political wars between WinDev and DevTools are quite well known, e.g. Longhorn (in .NET) vs WinRT (same thing just in COM).

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by Gibbon1 on Wednesday December 02, 2020 @02:57PM (#25280786)

Proper thing is bounds checking should be by default and you actually have to turn it off for hot path code. Because 99% of the code people write isn't memory or CPU bound. If a little used code path is sometimes throwing bounds exceptions you want that to get logged in production.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by pjmlp on Wednesday December 02, 2020 @03:10PM (#25280932)

Check C.A.Hoare Turing award speech in 1981 regarding the use of bounds checking in the 60's and how customers of Algol compilers considered a legal offence to even turn them off.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by lorenzhs on Wednesday December 02, 2020 @08:07AM (#25275966)

libstdc++ also has a debug mode with bounds checking etc, although you have to enable it by defining _GLIBCXX_DEBUG: https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.h...

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by pjmlp on Wednesday December 02, 2020 @09:31AM (#25276627)

Thanks for the heads up.

[ Parent | on HN ]

Re:An iOS zero-click radio proximity exploit odyssey by saagarjha on Tuesday December 01, 2020 @11:08PM (#25273142)

I read this line:

> Gets added to Visual C/C++, LLVM, and Gnu C as an extention.

And had to do a double-take because I thought you were talking about gets(3)…

[ Parent | on HN ]