Apple very begrudgingly allowed creation of alternative AppStores (marketplaces) instead, which are still completely under Apple’s technical control, and still go through Apple’s review.
Apple requires having a 1 million dollar credit line to allow opening a 3rd party AppStore, so consumers or small devs can’t just bypass Apple’s AppStore.
This has Toyota's fingerprints all over it. It's all of Toyota's talking points. It's especially suspicious that the top list includes Toyota's Lexus RZ and bZ4X which are the worst by far among BEVs [1] in terms of efficiency.
The article mentions expanding capabilities to support self-referential structs.
Currently structs are allowed to borrow from any data outside of them, but not from any of their own fields. Rust doesn't want to have move constructors, and borrowing from inline fields can't be safe, but borrowing from heap-allocated data owned by the same struct should be possible, and currently there's no non-hacky way to express that.
I was specifically referring to the ability to borrow a set of fields/paths. Enabling more useful self-referential structs would be something more novel.
A bounds-checked slice type would be a relatively small addition to C, and if adopted, it would make size tracking and bounds checking easier.
However, there's generally a strong pushback from C developers against features that have an unnecessary performance overhead.
Having reliable bounds checking without run-time cost if a much more complicated problem. Rust uses iterators for this, but that requires generics and specialization, and compared to C, these are big and complex features.
To be clear, I don't think there is any hope of implementing any protections at the language level in C, the push back would be exceptionally fierce. Although I do agree that a 'slice' type in the stdlib would not be to much to ask for.
My comment was more for consideration in the design of new languages, in particular, the development of the frequently cited as not existing, simple, C-like language with memory safety features. In that case, in a green field scenario, there are a few ways to achieve statically known memory-boundary respecting iteration and general access. Further, there are several existing methods of achieving 'generics'. The real design challenge would be in finding the simplest implementation that does not overly burden potential developers.
I am confident that it could be done, but it would take some grave dissatisfaction with Rust (which is currently at the top of the adoption curve in the memory safe, but GC free space) for the proposed language to take off.
The problem with slices in C being added in stdlib would be that they really are a generic data type. It would be similar to atomic types. While C++ could just add std::atomic<T>, C needed to add a special construct: _Atomic(T).
C++ already has a slice type. It’s called std::span<T>. Porting it to C would probably require something similar to atomics. At which point I guess you may just as well get on with it and switch to C++.
C++ chose not to have bounds checking on span’s operator[] by default. Like with vector, approximately nobody will use .at().
Buffer overflow vulnerabilities are where programmers thought they don’t need a bounds check, so having this as a choice every time, with the safer option looking worse, is working against it.
A nice minimal built-in syntax for spans (like Rust’s slices) could be an incentive to keep the bounds checks, and eventually make bare pointer arithmetic stand out as riskier.
I think this is more of a social problem with C++. Regardless whether the feature is implemented in the standard library or the core language, the broader C++ community is not going to approve of enabling bounds checks on the bracket operator. And whether this operator is implemented as a builtin or as an overload on an stdlib type is basically transparent to the user.
FWIW you can enable bounds checks for the bracket operator by default for STL types in GCC and Clang. So for interfacing with Rust it is both obvious how to translate between slices in Rust and std::span in C++, and you can verify to a degree that this std::span isn’t corrupted on C++ side (to a degree).
Apple could have an API for putting a Cancel button and other info for 3rd party subscriptions in the unified subscription screen. App Store requirement to integrate subscriptions with it would be uncontroversial, unless they also slapped a 27% because-we-can fee on that API.
Apple creates these either-or narratives that you either accept exactly what they want at their egregiously inflated price, or you will get the crappiest most inconvenient basically fraudulent alternative. As if nothing was possible in between.
This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++. It even explicitly notes complete rewrites are too challenging! The memo is quite broad, and goes beyond just the language choice. It also gives formal verification and CHERI as options for mitigating language unsafety. It refers to NSA's plan that goes even further into mitigations for existing codebases.
The article also rides on the contempt for PHP to make migration from C/C++ sound stupid, but PHP is not a real contender for systems programming, and isn’t on the list of recommended memory safe languages. It’s a “but what about all the other bugs”, as if having memory unsafety bugs somehow prevented all other kinds of bugs. It plays on the trope that real programmers use C++, and won't write bugs like the amateurs using blub languages.
The memo recognizes that CVE counting is problematic and calls for research into better vulnerability tracking and evaluation to get a better picture of actual risks, and address overall quality issues, not just memory safety.
> This article is strawman-ish, because the WH memo doesn’t suggest anything close to “outlawing” C or C++.
Maybe not outlaw, but I think in the long term the outcome will be similar. Memory unsafe? No government contract for you! Credit cards details leaked? Well not being memory safe was negligent, no insurance payout for you.
I think eventually all criticial infrastructure (including their dependencies, including libraries but also OS) will be be basically required to be memory safe.
That's exactly what the GP pointed that isn't on the memo.
But if you insist on using unsafe languages, and not using any of the tools and procedures available for making those safer, then yes, no contract money for you, and no insurance if something happens.
A lot of contracting is just developing to spec and/or working directly on-site just like regular employees. The government is going to have to dogfood this approach inasmuch as they want this to work.
That seems to be exactly the point that even the “not my problem” lowest bidder will have to start paying attention to security, and use a safer language, or hardware mitigations, or sandboxing instead of shipping something that could become a potential backdoor.
Currently people are making very pragmatic changes that doesn't require an impossible retooling of the entire area. The direction is clearly against carefree software, but nobody seems to be moving any fast on that way.
We don't even know if people will hold that direction on the long term. This is not the first pro-security cultural change that happened in computing, and it's not even touching the fact that the computers themselves are not secure.
I think that’s why Rust managed to get a foot in the door.
It doesn’t look like C with an extra feature or two, so it doesn’t get dismissed as an incremental improvement that could be DIYed in C instead (at least not by people who understand what Rust does).
Safety helps justify use of Rust it in places where this is important, but developers stick with it for all the other quality of life improvements.
If you only fix safety in C, you’ll still have C, with all the 1970’s clunkiness.
rav1e is generally head to head with libaom on static images, and which one wins on the speed/quality/size frontier depends a lot on the image and settings, as much as +/- 20%. I suspect rav1e has an inefficient block size selection algorithm, so the particular shape of blocks is a make or break for it.
I’ve only compared rav1e to mozjpeg and libwebp, and at fastest speeds it’s only barely ahead.
Apple very begrudgingly allowed creation of alternative AppStores (marketplaces) instead, which are still completely under Apple’s technical control, and still go through Apple’s review.
Apple requires having a 1 million dollar credit line to allow opening a 3rd party AppStore, so consumers or small devs can’t just bypass Apple’s AppStore.