Live data from Hacker News

The C23 edition of Modern C

gustedt.wordpress.com

151–160 of 360 posts

Re: The C23 edition of Modern C

#151
post #42

Earlier quoted context omitted.

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

It should be ++C because with C++ the value you get from the expression is the old one. If you're asking why people use pre-increment by default instead of post-increment, it's mostly historical. The early C compilers on resource-constrained platforms such as early DOS were not good at optimization; on those, pre-increment would be reliably translated to a simple ADD or INC, whereas code for post-increment might gene…

> It should be ++C because with C++ the value you get from the expression is the old one.

You get it!

Re: The C23 edition of Modern C

#152
post #102
post #72

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.

That's implementation defined behavior, not undefined behavior. Undefined behavior explicitly refers to something the compiler does not provide a definition for, including "safe defaults."

The C standard says, and I quote:

>Possible undefined behavior ranges from ignoring the situation completely with unpredictable results ... or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message)

So a compiler is absolutely welcome to make undefined behavior safe. In fact every compiler I know of, such as GCC, clang, MSVC has flags to make various undefined behavior safe, such as signed integer overflow, type punning, casting function pointers to void pointers.

The Linux kernel is notorious for leveraging undefined behavior in C for which GCC guarantees specific and well defined behavior.

It looks like there is also the notion of unspecified behavior, which gives compilers a choice about the behavior and does not require compilers to document that choice or even choose consistently.

And finally there is what you bring up, which is implementation defined behavior which is defined as a subset of unspecified behavior in which compilers must document the choice.

Re: The C23 edition of Modern C

#153

Earlier quoted context omitted.

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

Why use this operator? Like most C and C++ features the main reason tends to be showing off, you learned a thing (in this case that there are four extra operators here) and so you show off by using it even if it doesn't make the software easier to understand. This is not one of those beginner -> journeyman -> expert cycles where coincidentally the way you wrote it as a beginner is identical to how an expert writes it…

They can be useful when adding things to an array in a loop. A trivial example which removes a character from a null terminated string:

  void remove_char(char *s, char c) {
    size_t i, j;

    for (i = j = 0; s[i] != '\0'; i++)
      if (s[i] != c)
        s[j++] = c;
    s[j] = '\0';
  }

This might be better expressed with a higher order filter function, but C is too low level for things like that.

There are also idioms for stack manipulation using them: "stack[sp++] = pushed" and "popped = stack[--sp]".

C code does a lot of incrementing and decrementing by one, and so having dedicated syntax for it is convenient.

Re: The C23 edition of Modern C

#154
post #80

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.

This was a tip my hatn excellent to you

Re: The C23 edition of Modern C

#155
post #68

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 features a conforming C implementation which is known to catch all array bounds violations. ;)

That actually really does exist already with CHERI CPUs, whose pointers are tagged with "capabilities," which catch buffer overruns at runtime.

https://tratt.net/laurie/blog/2023/two_stories_for_what_is_c...

https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

Re: The C23 edition of Modern C

#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" and "nullptr" just reeks of C++.

That said, Modern C is an incredible book, I have been using it for C99 (which I intend to continue sticking to).

Re: The C23 edition of Modern C

#157
post #82
post #72

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 definition given by the C standard allows for safe undefined behavior.

Re: The C23 edition of Modern C

#158
post #80

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.

Why?

Re: The C23 edition of Modern C

#159
post #142

Earlier quoted context omitted.

Yeah, why have any type of human interaction in a forum when you can just refer your fellow brethren to the automaton.

I’m saying this because any explanation I could offer would provide less insight than the Google results.

Less insight, perhaps, but of higher quality, which is subjective.

I personally find that googling stuff provides not much connection to the subject of study, very impersonal and try to avoid it.

For example I did google the concept, and found this https://github.com/cousteaulecommandant/ds9k.

Which is not trivial to parse, bing posited the answer as authoritative, and if you look at the code it is really nothing, it seems to be a folklore concept, and as such, it is much more aptly transmitted by speaking to a human and getting a live version than by googling an authoratitative static answer.

Re: The C23 edition of Modern C

#160

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…

> what is wrong with NULL?

For starters, you have to #include a header to use it.

Post reply on HN