I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage.

It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's totally possible in C to produce good looking but actually invalid arguments that can't be spotted at runtime without UB (out of bounds access etc).

Edit: Actually thinking about this more, I guess the problem is that you are likely linking against a release library implementation, so it's not possible to add a precondition without introducing a runtime overhead, which is probably more likely what we are talking about with this case.

Look at the addressing modes for the PDP-11 in https://en.wikipedia.org/wiki/PDP-11_architecture and you'll see you can write (R0)+ to read the contents of the location pointed to by R0, and then increment R0 afterwards (so a post increment).

Back in the day, compilers were simple and optimisations weren't that common, so folding two statements into one and working out that there were no dependencies would have been tough with single pass compilers.

You could argue that without such instructions, C wouldn't have been embraced quite so enthusiastically for systems programming, and the world would have looked rather different.

This would have been in the late 80s - i've no idea if it was still in use, but i've a feeling that the law hadn't necessarily moved on, so I guess the official measure could have been required if challenged in court.

The calibration procedure on the scope fiddles with the time alignment to get the different DACs correctly offset so that the combined signal is correct.

The hybrid ceramic input boards in their metal cases are a thing of beauty, fragile (don't ask how I know), but beautiful.

Interesting that it's mandated as native - i'm really not sure the logic behind this (i've worked in the embedded world where such stuff is not only normal, but the only choice). I'll do some digging and see if I can find the thought process behind this.

So, >foo is the same as 1>foo

If you want to get really into the weeds, I think 2>>&1 will create a file called 1, append to a file descriptor makes no sense (or maybe, truncate to a file descriptor makes no sense is maybe what I mean), but why this is the case is probably an oversight 50 years ago in sh, although i'd be surprised if this was codified anywhere, or relied upon in scripts.

It was a very flexible and hackable system, very fragile, and no security whatsoever, but lots of fun!

Of course these days with LTO the whole performance space is somewhat blurred since de-virtualisation can happen across whole applications at link time, and so the presumed performance cost can disappear (even if it wasn't actually a performance issue in reality). It's tough to create hard and fast rules in this case.

If we take a Tesla model 3, I believe it weighs 1611kg, and the motor shows up at 80kg if you google it (no idea if this is correct). This YASA motor by comparison weighs 14kg. So, this would drop the vehicle weight by 66kg out of 1611, so that's a 4% saving.

https://www.bbc.co.uk/rd/blog/2024-03-c2pa-verification-news...

I believe various cameras support this, e.g. https://www.canon-europe.com/press-centre/press-releases/202...

`C2PA Authenticity: Integrated support for the C2PA standard for photo authenticity verification – initially available exclusively for registered news agencies.`

Sounds like it's limited to some users for now, I guess this will change in the future.

Going too far won't really help, since the scene being photographed can be manipulated or staged, which sounds more likely to be a concern rather than the hardware being hacked.