261–270 of 360 posts
Earlier quoted context omitted.
UB is does not automatically make things unsafe. You can have a compiler that implements safe defaults for most UB, and then it is not unsafe.
By definition UB cannot be safe.
> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…
MIPS is still quite alive in consumer networking hardware.
¹ on the OpenWRT table of hardware
> The storage order, the endianness, as given for my machine, is called little-endian. A system that has high-order representation digits first is called big-endian. Both orders are commonly used by modern processor types. Some processors are even able to switch between the two orders on the fly. Calling big endian "commonly used by modern processor types" when s390x is really the only one left is a bit of a stretch…
"Modern" doesn't mean "currently widespread".
Earlier quoted context omitted.
"Modern" doesn't mean "currently widespread".
Indeed, if it meant "currently widespread" there'd be a stronger argument for Big Endian with a lot of MIPS and PPC chugging away silently. But interpreting "modern" as recent development, BE is close to gone.
Earlier quoted context omitted.
Indeed, if it meant "currently widespread" there'd be a stronger argument for Big Endian with a lot of MIPS and PPC chugging away silently. But interpreting "modern" as recent development, BE is close to gone.
Is there some end to this criticism or do you have some stake in dismissing big endian architectures?
If you can't live without knowing, sure, my stake in dismissing big endian architectures is that I can't in fact dismiss BE architectures because I have users on it. And it's incredibly painful to test because while my users have such hardware, actually buying a good test platform or CI system is close to impossible. (It ended up being Freescale T4240-QDS devkits off eBay. Not a good sign when the best system you can get is from a company that doesn't exist anymore.)
And at some point it's a question about network protocols/encodings being designed to a "network byte order" determined in the 80s to be big endian. When almost everything is LE, maybe new protocols should just stick with LE as well.
Earlier quoted context omitted.
Speaking more broadly than just the std implementation, but result types like optional shouldn't be a 2% convenience, they should be used in most function calls that return errors. Rust is the obvious example here.
If you argue for Rust I'm all for it, arguably much less of a learning curve than C++ too.
One exception to that in my experience: dependencies, although I think that's a bit deceiving as yes, it's easier to get dependencies in Rust but in some areas they're way less mature and can sometimes be a pain to work with (usually when dealing with big C or C++ libraries that have been quickly glued to a Rust interface to be available in Rust).
Earlier quoted context omitted.
fscanf (STDIN, "%d", &a); the program goes beserk as soon as the first non-number is read out of standard input. in both cases, you need error checking (which you "know about").
No actual C programmer who has been around the block more than halfway should do that. The mantra is: "read into a character buffer, then parse that". It's more code, sure, but it buys you a lot of good things. I/O is hard.
cin >> a;
But also ...
sscanf (the_buffer, "%d", &a);
I am worried where "official" C is going. Its syntax which is already too complex and already does too much, but that would require to "break" backward compatibility namely it would require "porting". But since it would be still "C" that amount of work should be close to "a bit" of "step by step" refactoring For instance, only sized types:u8...s64, f32, f64... no implicit casts except for void* and literals, no integ…
> I tend to stick to C99, > […] But we would need explicit atomics, explicit memory barriers, […] You should read a change summary before complaining about bits missing from C99 that have in fact been added to C11. > […] no toxic attribute like "packed structure" which makes us lose sight of data alignment […] And you should also familiarize yourself with what's in actual ISO C vs. compiler extensions before complain…
The pb is in ISO c11+ we got some of the missing stuff for modern hardware architecture, but also tons of tantrums (_generic, typeof, restrict....)
Earlier quoted context omitted.
Is there some end to this criticism or do you have some stake in dismissing big endian architectures?
Uh, why so serious? I called it "a bit of a stretch ;D" - there was a reason for that smiley. I'm well aware BE is alive enough to be around. If you can't live without knowing, sure, my stake in dismissing big endian architectures is that I can't in fact dismiss BE architectures because I have users on it. And it's incredibly painful to test because while my users have such hardware, actually buying a good test platf…
Personally this[1] just makes C much more complicated for me, and I choose C when I want simplicity. If I want complicated, I would just pick C++ which I typically would never want. I would just pick Go (or Elixir if I want a server). "_BitInt(N)" is also ugly, reminds me of "_Bool" which is thankfully "bool" now. [1] guard, defer, auto, constexpr, nullptr (what is wrong with NULL?), etc. On top of that "constexpr" a…
The old definition did not even specify wether it was a pointer or an integer. So for platforms that did not follow the Posix ((void*)0) requirement it was a foot gun that had neither the type nor the size of a pointer.
> On top of that "constexpr" and "nullptr" just reeks of C++.
Probably because they where back ported from C++. You can still use NULL, since that was apparently redefined to be nullptr.