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

71–80 of 360 posts

Re: The C23 edition of Modern C

#71

Post by uecker »

layer8 wrote: post #68
WalterBright wrote: post #60

Earlier quoted context omitted.

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.

> no array bounds checking is possible. This isn’t strictly true, a C implementation is allowed to associate memory-range (or more generally, pointer provenance) metadata with a pointer. The DeathStation 9000 features a conforming C implementation which is known to catch all array bounds violations. ;)

Right. Also it might it sound like array-to-pointer decay is forced onto the programmer. Instead, you can take the address of an array just fine without letting it decay. The type then preserves the length.

Re: The C23 edition of Modern C

#72

Post by uecker »

renox wrote: post #59
ralphc wrote: post #41

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

You'd be surprised: Zig has one UB (Undefined Behaviour) that C doesn't have! In release fast mode, unsigned overflow/underflow is undefined in Zig whereas in C it wraps. :-) Of course C has many UBs that Zig doesn't have, so C is far less safe than Zig, especially since you can use ReleaseSafe in Zig..

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.

Re: The C23 edition of Modern C

#73

Post by tjoff »

AlotOfReading wrote: post #64
tjoff wrote: post #35

Earlier quoted context omitted.

The killer feature of RAII is when combined with exceptions. But sneaking in exceptions in an embedded C project isn't something I'd encourage or recommend. C++ imo doesn't offer anything compelling for the embedded usecase. Especially not considering all the footguns and politics it brings. You can of course be strict and diligent about it but if you are you are pretty much just writing C anyway. Better to do it exp…

C++ offers lots of compelling things for embedded use cases, like enum classes (finally fixed in C23), constexpr, std::optional, namespaces, and atomics/generics that are much smaller dumpster fires. There's an effort to extract the good parts and make it work for embedded use cases or even bring them into C. Khalil Estelle on WG21 has been working on an experimental, deterministic runtime for exception handling, to…

I don't disagree, but these are in the ~2% convenience at most. With the huge baggage of including C++ in a project. The cost of learning C++ easily outweighs all those benefits. If you happen to have a proficient C++ team (that actually know embedded), go for it!

Re: The C23 edition of Modern C

#74

Post by pjmlp »

flohofwoe wrote: post #23
pjmlp wrote: post #4

Earlier quoted context omitted.

Specially relevant to all those folks that insist on "Coding C with a C++ compiler", instead of safer language constructs, and standard library alternatives provided by C++ during the last decades.

Funny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

Yeah, 12 years ago, when governments couldn't care less about nation state cyberattacks, and Microsoft was yet to be called by the Congress to testify on their failures.

Re: The C23 edition of Modern C

#75

Post by Quekid5 »

card_zero wrote: post #39
jejdjdbd wrote: post #32

Earlier quoted context omitted.

Why would you use post increment by default? The semantics are very particular. Only on very rare occasions I need post increment semantics. And in those cases I prefer to use a temporary to make the intent more clear

People seem to mostly write a typical for loop ending with ; ++i){ But I write ; i++){ and seeing it the other way round throws me off for a minute, because I think, as you put it, why would you use those very particular semantics? But I guess this is only a semantic argument.

I've seen either style, but it the argument about which is proper is pointless. Any modern compiler will optimize either equally well, unless you're doing something that actually depends on the order of the increment.

Re: The C23 edition of Modern C

#76

Post by Someone »

jasode wrote: post #45
belter wrote: post #2

Important reminder just in the Preface :-) Takeaway #1: "C and C++ are different: don’t mix them, and don’t mix them up"

>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…

> C++ code can seamlessly add #include "sqlite3.h" unchanged.

Almost seamlessly. You have to do

  extern “C” {
    #include "sqlite3.h"
  }
(https://isocpp.org/wiki/faq/mixing-c-and-cpp#include-c-hdrs-...)

Re: The C23 edition of Modern C

#77

Post by pjmlp »

rdtsc wrote: post #43
flohofwoe wrote: post #23

Earlier quoted context omitted.

Funny because for a long time the Microsoft MSVC team explicitly recommended compiling C code with a C++ compiler because they couldn't be arsed to update their C frontend for over two decades (which thankfully has changed now) ;) https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...

That thing always baffled me, this huge company building a professional IDE couldn't figure out how to ship updates to the C compiler. > it is hard to say no to you, and I’m sorry to say it. But we have to choose a focus, and our focus is to implement (the standard) and innovate (with extensions like everyone but which we also contribute for potential standardization) in C++. I mean, yeah if it came from a two member…

It was on purpose, Microsoft was done with C, the official message was to move on to C++.

The change of heart was the new management, and the whole Microsoft <3 FOSS.

Re: The C23 edition of Modern C

#79

Post by pjmlp »

com2kid wrote: post #11
pjmlp wrote: post #4

Earlier quoted context omitted.

Specially relevant to all those folks that insist on "Coding C with a C++ compiler", instead of safer language constructs, and standard library alternatives provided by C++ during the last decades.

Perfectly valid to do if you need to interface with a large C code base and you just want to do some simple OO here and there. Especially if you cannot have runtime exceptions and the like. This is how I managed to sneak C++ into an embedded C codebase. We even created some templates for data structures that supported static allocation at compile time.

Yeah, but one should provide C++ type safe abstractions on top.

Just like one doesn't use Typescript to keep writing plain old JavaScript, then why bother.

Re: The C23 edition of Modern C

#80

Post by pjmlp »

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…

Perfectly iostreams happy user since 1993.
Post reply on HN