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

311–320 of 360 posts

Re: The C23 edition of Modern C

#311

Post by unscaled »

legends2k wrote: post #301
eqvinox wrote: post #253

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

Arm is bi-endian and is alive in most phones. I agree with another GP's comment that modern doesn't mean popular/widely used.

The book does say "Both orders are commonly used by modern processor types". I'd say this sentence is quite misleading, since it would lead you to believe two falsehoods:

1. That both byte orders are equally prevalent in the wild, particularly in systems that are expected to run modern C code.

2. That both byte orders are equally likely to be found in "modern" (new or updated) processor design.

It's not entirely incorrect, but a better phrasing could be used to clarify that little-endian is the more modern and common storage order, but you still cannot ignore big-endian.

Re: The C23 edition of Modern C

#312

Post by cmovq »

flohofwoe wrote: post #306
unilynx wrote: post #286

Earlier quoted context omitted.

well in a way all processors commonly use them... as big-endian is also the network byte order

...x86 CPUs actually have special mov instructions now to load big endian data. Not sure since when though (on godbolt it needs `-march=native`: https://www.godbolt.org/z/bWfhGx7xh ...without -march=native it's a mov and bswap (so not too bad either).

Looks like it was introduced with Haswell (2013). So it’s safe to use if you’re also compiling with AVX2.

Re: The C23 edition of Modern C

#313

Post by pornel »

chongli wrote: post #294
pornel wrote: post #250

Earlier quoted context omitted.

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

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. The issue is that these great new tools don't just fix the old vulnerabilities, they also provide a lot of new, powerful footguns for people to play with. They're shipping 2000 feet of rope with every language when all we need is 6 feet to hang ourse…

There has been a bunch of failed C killers, and C++ has massively shat the bed, so I understand that people are jaded.

However, this pessimistic tradeoff is just not true in case of Rust — it has been focused from the start on preventing footguns, and actually does a great job of it. You don't trade one kind of failure for another, you replace them with compilation errors, and they've even invested a lot of effort into making these errors clear and useful.

Re: The C23 edition of Modern C

#314

Post by eqvinox »

legends2k wrote: post #303
School-Cotton wrote: post #302

Earlier quoted context omitted.

I really doubt any mainstream smartphone runs their Arm chip in big-endian mode ever.

That's besides the point. The book's author has a valid point. Being pedantic should be applied at all levels if you're going that route.

The problem about being pedantic is that you can choose different directions to be pedantic in. My "direction" is that code isn't written in a vacuum, it mixes with code millions of other people wrote and runs on machines millions of other people built. As such:

My concern isn't that the phrasing in the book is wrong, and I have expressly not argued that. It's that it presents the issue as having no further depth, and these two choices as equivalent. They aren't. The "Some processors are even able to switch between the two orders on the fly." that follows makes it even worse, at least to me it really sounds like you needn't give any care.

And the people reading this book are probably the people who should be aware of more real-world background on endianness, for the good of the next million of people dealing with what they produced.

Re: The C23 edition of Modern C

#315

Post by steveklabnik »

throwaway2037 wrote: post #164
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…

Over the years, I have heard numerous complaints about C++ I/O streams. Is there a better open source replacement? Or do you recommend to use C functions for I/O?

https://en.cppreference.com/w/cpp/utility/format for C++20 and https://en.cppreference.com/w/cpp/io/print for C++23

https://github.com/fmtlib/fmt is what it's based on, for C++11 and up support.

Re: The C23 edition of Modern C

#316

Post by uvas_pasas_per »

fluoridation wrote: post #295
uvas_pasas_per wrote: post #273

I've been using modern C++ for a personal project (a language interpreter) for the last year+. I constantly think of switching to C, because of the mental burdens of C++, and because of the problems with tooling (Visual Studio's IntelliSense still barely works, because I use C++20 modules), and compile times get ugly because of the way the language failures force so much into interfaces (even with modules). But on th…

I've been using C++ for the longest time, and I would never give up destructors to switch to C. For your particular use case, have you considered C#? VS works much more nicely with it.

Yeah, I did. I want something low level and cross platform, including mobile. I think when I tried the C# for iOS stuff, nothing worked. But it's probably too much VM/runtime for me anyway, for this project.

Re: The C23 edition of Modern C

#317

Post by fluoridation »

uvas_pasas_per wrote: post #316
fluoridation wrote: post #295

Earlier quoted context omitted.

I've been using C++ for the longest time, and I would never give up destructors to switch to C. For your particular use case, have you considered C#? VS works much more nicely with it.

Yeah, I did. I want something low level and cross platform, including mobile. I think when I tried the C# for iOS stuff, nothing worked. But it's probably too much VM/runtime for me anyway, for this project.

Fair enough. I would've used C++ as well.

Re: The C23 edition of Modern C

#318

Post by rbanffy »

pjmlp wrote: post #212
flohofwoe wrote: post #205

Earlier quoted context omitted.

One advantage of writing C code is that you don't have annoying discussions about what idiomatic code is supposed to look like, and what language subset is the right one ;) For the cutting edge I would recommend Zig btw, much less language complexity than both modern C++ and Rust. One good but less visible side effect of C23 is that it harmonizes more syntax with C++ (like ... = {} vs {0}) which makes it a bit less a…

There is enough material in C, and related compiler extensions, to have similar discussions, starting from where to place brackets.

Maybe the C24 will define the One Right Way.

Re: The C23 edition of Modern C

#319

Post by wakawaka28 »

pjmlp wrote: post #206
wakawaka28 wrote: post #141

Earlier quoted context omitted.

C and C++ are the bedrock of operating systems with the best performance and extensive support for all languages. The only reason why iostreams are slow is because of its incompatible buffering scheme, and the fact that C and C++ need to stay in sync when linked together. And that brand of slow is still faster than other languages, except sometimes those that delegate i/o to pure C implementations.

Historical baggage, they weren't the first system programming languages, got lucky with UNIX's license allowing for widespread adoption, and won't be the last one standing either.

Considering that they are evolving, I think they are more likely than not to stay standing. There might be other similar languages developed in parallel, but after over 30 years of whining C and C++ are still popular. I don't expect that to change.

Re: The C23 edition of Modern C

#320

Post by WalterBright »

uecker wrote: post #214
WalterBright wrote: post #139

Earlier quoted context omitted.

C: int foo(int a[]) { return a[5]; } int main() { int a[3]; return foo(a); } > gcc test.c > ./a.out Oops. D: int foo(int[] a) { return a[5]; } int main() { int[3] a; return foo(a); } > ./cc array.d > ./array core.exception.ArrayIndexError@array.d(1): index [5] is out of bounds for array of length 3 Ah, Nirvana! How to fix it for C: https://www.digitalmars.com/articles/C-biggest-mistake.html

You need to take the address of the array instead of letting it decay and then size is encoded in the type: int foo(int (*a)[6]) { return a[5]; } int main() { int a[3]; return foo(&a); } Or for run-time length: int foo(int n, int (*a)[n]) { return (\*a)[5]; } int main() { int a[3]; return foo(ARRAY_SIZE(a), &a); } /app/example.c:4:38: runtime error: index 5 out of bounds for type 'int[n]' https://godbolt.org/z/dxx7Ts…

  int foo(int n, int (*a)[n]) { return (\*a)[5]; }
  int main() {
    int a[3];
    return foo(ARRAY_SIZE(a), &a);
  }
That syntax is why array overflows remain the #1 problem with C bugs in shipped code. It isn't any better than:

  int foo(size_t n, int* a) { assert(5
as the array dimension has to be handled separately from the pointer.

Contrast with how simple it is in D:

    int foo(int[] a) { return a[5]; }
    int main() {
        int[3] a;
        return foo(a);
    }
and the proof is shown by array overflow bugs in the wild are stopped cold. It can be that simple and effective in C.
Post reply on HN