Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

Post reply on HN
Print view View original

241–250 of 360 posts

Re: The C23 edition of Modern C

#241

Post by eqvinox »

flohofwoe wrote: post #204
johnisgood wrote: post #156

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…

auto is mostly useful when tinkering with type-generic macros, but shouldn't be used in regular code (e.g. please no 'almost always auto' madness like it was popular in the C++ world for a little while). Unfortunately there are also slight differences between compilers (IIRC Clang implements a C++ style auto, while GCC implements a C style auto, which has subtle differences for 'auto pointers' - not sure if those dif…

> AFAIK defer didn't actually make it into C23?

Correct, defer didn't make it into C23.

It (in its __attribute__((cleanup())) form) is also one of the most useful extensions in GCC/clang — but, again, for use in macros.

Re: The C23 edition of Modern C

#242

Post by sdk77 »

WalterBright wrote: post #60
ralphc wrote: post #41

How does "Modern" C compare safety-wise to Rust or Zig?

Modern C still promptly decays an array to a pointer, so no array bounds checking is possible. D does not decay arrays, so D has array bounds checking. Note that array overflow bugs are consistently the #1 problem with shipped C code, by a wide margin.

The thing is though that even with array bounds checking built into the language, out of bounds access due to programming error can still be attempted. Only this time it's safer because an attacker can't use the bug (which still exists) to access memory outside of bounds. In any case, the program still doesn't work as intended (has bugs) because the programmer has attempted, or allowed the attempt, to access out of bounds memory.

Writing safe code is better than depending on safety features. Writing safe code is possible in any programming language, the only things required are good design principles and discipline (i.e. solid engineering).

Re: The C23 edition of Modern C

#243

Post by uecker »

pornel wrote: post #225
uecker wrote: post #208

Earlier quoted context omitted.

Most of us liking a good language just did not use MSVC. I do not think many people who appreciate C's simplicity and stability would be happy with C++ / Rust. Zig is beautiful, but still limited in many ways and I would not use it outside of fun projects.

I don't even use Windows, but I need to write portable libraries. Unfortunately, MSVC does strongly influence the baseline, and it's not my decision if I want to be interoperable with other projects. In my experience, Windows devs don't like being told to use a different toolchain. They may have projects tied to Visual Studio, dependencies that are MSVC-only or code written for quirks of MSVC's libc/CRT, or want uniq…

The good news is that MSVC has C17 support (still missing important optional features, but at least some progress).

Re: The C23 edition of Modern C

#244

Post by uecker »

survivedurcode wrote: post #185

Continuing to use a memory-unsafe language that has no recourse for safety and is full of footguns and is frankly irresponsible for the software profession. God help us all. By the way, the US government did the profession no favors by including C++ as a memory-unsafe language. It is possible to write memory-safe C++, safe array dereferencing C++. But it’s not obvious how to do it. Herb Sutter is working on it with C…

There good tools that help improving memory safety in C and I do not think Rust is a good language. Of course, the worst about Rust are its fans.

Re: The C23 edition of Modern C

#245

Post by eqvinox »

sylware wrote: post #238

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 complaining about bits that are in fact compiler extensions.

Re: The C23 edition of Modern C

#246

Post by flohofwoe »

pjmlp wrote: post #215
dhhfss wrote: post #194

Earlier quoted context omitted.

This depends on the platform. Many embedded systems are based on arm these days and have modern toolchains available. I cannot remember the last time I saw C99 used. C codebases generally use C11 or C17, and C++ code bases use C++20

Unless you can vouch for the C++ compiler, the best C++ portable code can offer today is C++17. Also 8 and 16 bit embedded toolchains are certainly not on C11 / C17, they can hardly afford full C89.

SDCC is a niche C compiler for 8-bit CPUs and is more uptodate than MSVC ;P

https://sdcc.sourceforge.net/

That's the nice thing with C: it's much easier for small teams to fully support than the latest C++ standards.

Re: The C23 edition of Modern C

#247

Post by beeforpork »

n_plus_1_acc wrote: post #115
layer8 wrote: post #62

Earlier quoted context omitted.

The idiomatic void strcpy(char *s, char *t) { while (*s++ = *t++) ; } (straight from K&R) wouldn’t work without it.

Which many people find unreadable compared to other versions.

And for several reasons.

  * is it (*s)++ or *(s++)?
  * it is not *++s nor ++*s
And I have seen

  *(*s)++
in some places!

It is concise syntax but very confusing.

Re: The C23 edition of Modern C

#248

Post by flohofwoe »

jandrese wrote: post #78
ralphc wrote: post #41

How does "Modern" C compare safety-wise to Rust or Zig?

Modern C is barely any different than older C. The language committee for C is extremely conservative, changes tend to happen only around the edges.

Except for C99 which added designated init and compound literals. With those it almost feels like a new language compared to C89 (and the C99 designated init feature is so well thought out that it still beats most similar initialization patterns in more recent languages, including C++, Rust and Zig - only Odin seems to "get it").

Re: The C23 edition of Modern C

#249

Post by chipdart »

tialaramex wrote: post #63
jasode wrote: post #45

Earlier quoted context omitted.

>Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up" Where "mixing C/C++" is helpful: - I "mix C in with my C++" projects because "sqlite3.c" and ffmpeg source code is written C. C++ was designed to interoperate with C code. C++ code can seamlessly add #include "sqlite3.h" unchanged. - For my own code, I take advantage of "C++ being _mostly_ a superset of C" such as using old-style C printf…

The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators so…

> The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby.

I think this is a very lazy and somewhat conspiratorial take.

C++'s IO stream library, along with C++'s adoption of std::string, is a response to and improvement over C's standard library support for IO. That alone makes it an invaluable improvement. It's easy and very lazy to look back 30 years ago and badmouth things done back then.

It's also easy to complain about no one proposing changes when literally anyone, including you, can propose changes. The only need to do the legwork and put their money where their mouth is. The funny part is that we see frameworks putting together their own IO infrastructure and it ends up being not good, such as Qt's take on IO.

But talk is cheap and badmouthing doesn't require a pull request.

Re: The C23 edition of Modern C

#250

Post by pornel »

worksonmine wrote: post #236
pornel wrote: post #229

Earlier quoted context omitted.

It's been a skill issue for 40 years. How long are we going to continue searching for those programmers who don't make mistakes?

Programmers make stupid mistakes in the safest languages too, even more so today when software is a career and not a hobby. What does it matter if the memory allocation is safe when the programmer exposes all user sessions to the internet because reading Dockers' documentation is too much work? Even Github did a variant of this with all their resources.

Because memory vulnerabilities don't make programs immune to other dumb mistakes. You get these vulnerabilities on top of everything else that can go wrong in a program.

Manual checking of memory management correctness takes extra time and effort to review, debug, instrument, fuzz, etc. things that the compiler could be checking automatically and reliably. This misplaced effort wastes resources and takes focus away from dealing with all the other problems.

There's also a common line of thinking that that because working in C is hard, C programmers must be smarter and more diligent, so they wouldn't make dumb mistakes like the easy-language programmers do. I don't like such elitist view, but even if true, the better programmers can allocate their smarts to something more productive than expertise in programs corrupting themselves.

Post reply on HN