Everyone drives that eventually.

All the fuel stations near me continue working when the power is down. What kind of backwards regressive area are you in where businesses that run on electricity don't have backup generators?

From this link over here:

Their solution was to add a footnote with an exception for memcpy, meaning that you can't implement memcpy() in C (your implementation has no exception).

It gets worse though:

So, once again, the standard crippled the implementors by making sure they can't use standards-compliant C to write the malloc/memcpy implementation, then turned tons of existing legal code into illegal code.

It actually gets a lot worse when you start reading up on the current interpretations of the standard.

Yeah, they added annex K (a good thing) then made it optional, so now there are C11-conforming programs which compile under one conforming implementation but not under another conforming implementation. They should've left it out completely or made it mandatory.

But, even mandatory, it still has problems (this is from a committee member, btw):

There's more but you'll have to search the interwebs cos I'm too busy and/or lazy to go looking for the myriads of articles I've read over the years complaining about the additions (like threads.h/thrd_t being incomplete) or the changes to existing behaviour (like malloc/memcpy). You can start by reading the proposal here which was eventually discarded anyway. Many good ideas for C are dead on arrival due to UB (super-optimisers, static+dynamic checking, etc).

The real problem is that a few tiny changes to the C standard could make a big difference, instead the committee is giving us crap (like annex K) which they make optional anyway[1]. If every new C standard removed one existing point of UB by clarifying the behaviour of that point we'd have a pretty solid language after only a few standards (Rumours are that a few members did propose to standardise signed-integer representation as twos-complement for C2x which makes a lot of security issues go away).

[1] The only reason annex K is in is because Microsoft, and Microsft alone, pushed (and pushed hard) for it to be included. Then when it was, they made their versions of the annex K functions behave differently to the annex K spec so if you use any of the annex K functions in MSVC, then even though your code will compile error-and-warning-free on every other conforming (annex K) compiler, it will have bugs and buffer overflows. Pretty sneaky, that.

Instead of reducing UB, they add new UB to the standard.

Amazing, certainly, but also a little sad. Many of the optimisations that can be done (or warnings that can be generated) are not being done/generated because of the huge body of code out there that will get broken/flagged, respectively.

Unfortunately, you cnanot blame the compiler writers nor can you blame the programmers themselves - the ANSI committee is filled with morons who have no intention of making the language spec less ambiguous. After their last standard they were dumbfounded to learn that the changes they made to the C99 standard turned memcpy into undefined-behaviour.

C persists for a reason, and that reason is simplicity and ease of understanding. C11 took the C++ approach and made well-understood C99 constructs confusing. There is no value in a C that is hard to read.

What do you mean "properly" supporting? I know that sizeof only works in the scope that a static array is defined in, because the compiler has that information even though the array does not know its own size. When that same array is passed to a function, the compiler does not have that information because the array does not know its own size.

I hate to be the one to break it to you, but arrays are a pointer to memory even before they are passed to a function. I don't know why you think that arrays magically change when they are passed - they are passed as-is, untouched by any processing, so they are exactly the same for the callee as they are for the caller.

I don't think you know what ROM means (hint - it is not a synonym for 'cartridge').

That makes perfect sense if you know what ROM means:

This week, a Read-Only Memory of a canceled 2007 Xbox 360 remaster of the game appeared online [...]

So, about double the record for C++ then.

Good point - people pray harder in a casino than in a church.

To be fair, this was on the wall ever since we saw over the last decade how a vocal minority can have a disproportionate silencing effect on the majority. Four butthurt snowflakes can get someone banned? Imagine what three million redditors can do. And now we don't have to imagine anymore, we saw what they did to Melvin Capital (and, indirectly, Robinhood, which can kiss 75% of their users goodbye).

To put things in perspective, the WSB mob probably had more actual support than BLM (more people poured their money into the cause for GameStop than for BLM)

Things are going to be interesting in the near future - the mob has discovered how strong it really is, and it's more likely that they will attempt a repeat of this, again and again.

This isn't a null-terminated string error. This error would have occurred even if you *were* using length indicators because it depends on overrunning the buffer due to the final character being an escape character.

How does having a length indicator prevent buffer overruns that using strlen() doesn't?

Doctors' ethical code enables them to provide services to anyone, even Hitler. This "ethical" forbids services to those some puritanical regressive deemed "immoral".

If you can't see the difference, you're part of the problem.

You own a cuecat too?

In practice, there is very little difference between Python and PHP. They both fail only at runtime if you make a type error.