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

91–100 of 360 posts

Re: The C23 edition of Modern C

#91

Post by [deleted] »

Someone wrote: post #76
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…

> 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-... )

[deleted]

Re: The C23 edition of Modern C

#92

Post by greyw »

secondcoming wrote: post #89
renox wrote: post #59

Earlier quoted context omitted.

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

Does C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.

Unsigned overflow wraps. Signed overflow is undefined behavior.

Re: The C23 edition of Modern C

#93

Post by renox »

secondcoming wrote: post #89
renox wrote: post #59

Earlier quoted context omitted.

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

Does C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.

-fwrapv is for signed integer overflow not unsigned.

Re: The C23 edition of Modern C

#94

Post by [deleted] »

secondcoming wrote: post #89
renox wrote: post #59

Earlier quoted context omitted.

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

Does C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.

[deleted]

Re: The C23 edition of Modern C

#95

Post by rdtsc »

pjmlp wrote: post #77
rdtsc wrote: post #43

Earlier quoted context omitted.

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.

> It was on purpose, Microsoft was done with C

Indeed, and yet here we are with C23

> The change of heart was the new management, and the whole Microsoft Yeah, agree. To me the turning point was when they created WSL.

Re: The C23 edition of Modern C

#96

Post by codr7 »

pjmlp wrote: post #80
tialaramex wrote: post #63

Earlier quoted context omitted.

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.

Same, as long as I stay the hell away from locales/facets.

Type safe input/output stream types and memory backed streams served on a silver plate is a pretty decent improvement over C.

Re: The C23 edition of Modern C

#97

Post by kbolino »

greyw wrote: post #92
secondcoming wrote: post #89

Earlier quoted context omitted.

Does C automatically wrap? I thought you need to pass `-fwrapv` to the compiler to ensure that.

Unsigned overflow wraps. Signed overflow is undefined behavior.

This distinction does not exist in K&R 2/e which documents ANSI C aka C89, but maybe it was added in a later version of the language (or didn't make it into the book)? According to K&R, all overflow is undefined.

Re: The C23 edition of Modern C

#98

Post by russellbeattie »

Wow, the use of attributes like [[__unsequenced__]], [[maybe_unused]] and [[noreturn]] throughout the book is really awful. It seems pretty pedantic of the author to litter all the code examples with something that is mostly optional. For a second I wondered if C23 required them.

Re: The C23 edition of Modern C

#99

Post by TZubiri »

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. ;)

"The DeathStation 9000"

The what now?

Re: The C23 edition of Modern C

#100

Post by codr7 »

jejdjdbd wrote: post #32
card_zero wrote: post #27

Earlier quoted context omitted.

Because people choose to use pre-increment by default instead of post-increment? Why is that?

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

If you're used to the idiom, the intent couldn't be clearer.

I miss it when switching between C/++ and other languages.

Post reply on HN