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

C23 Implications for C Libraries

htmlpreview.github.io

Post reply on HN
Print view View original

91–100 of 135 posts

Re: C23 Implications for C Libraries

#91

Post by dzaima »

ElevenLathe wrote: post #62
layer8 wrote: post #50

Earlier quoted context omitted.

It might remove too many compiler optimization opportunities (see e.g. http://kristerw.blogspot.com/2016/02/how-undefined-signed-ov... ) for the standard to disallow them now.

Meaning there are too many compilers currently producing fast-but-probably-not-what-the-programmer-meant code that will need to be changed produce slower-but-probably-what-the-programmer-meant code? Or do I misunderstand? Seems like a win to me if so.

If you do "for (int i = 0; i While two's complement signed rollover can be pretty useful, in 99% of cases you don't need it, and casting to unsigned for the 1% is a worthwhile sacrifice for the better optimizations for the common case, and it'll be pretty clear when you want wrapping or not (and sanitizers will be able to keep reporting signed overflow as errors without false positives).

Re: C23 Implications for C Libraries

#92

Post by kazinator »

quelsolaar wrote: post #68
vbtemp wrote: post #44

I have a question I've always wanted to know but too embarrassed to ask (Especially because I've extensively used C for well over a decade now and am intimately familiar with it): Who exactly are these new C-standards for? I interact and use C on an almost daily basis. But almost always ANSI C (and sometimes C99). This is because every platform, architecture, etc has at least an ANSI C compiler in common so it serves…

I'm in the WG14, and I, like you, only use c89. So why does c23 matter? Well in terms of features it matters very little but a big part of wg14s work is clarifying omissions from previous standards. So when c23 specifies something that has been unclear for 30+ years, compiler developers back port it in to older versions of C where it was simply unclear. It matters a lot for things like the memory model and things lik…

> compiler developers back port it in to older versions of C where it was simply unclear

You cannot rely on that. If you're maintaining C90 code, with a C90 compiler or compilation mode, you should go by what is written ISO 9899:1990, plus whatever the platform itself documents.

We actually don't want compiler writers mucking with the support for older dialects to try to modernize it. It's a backward-compatibility feature; if you muck with backward compatibility features, you risk breaking ... backward compatibility!

Re: C23 Implications for C Libraries

#93

Post by flohofwoe »

mathstuf wrote: post #89
flohofwoe wrote: post #58

Earlier quoted context omitted.

In my case: because writing C code (specifically C99 or later - designated init and compound literals!) gives me joy in a way that neither C++ nor Rust provide (C++ was my go-to language for nearly two decade between ca. 1998 and 2017), and I tinkered with Rust a couple of years ago, enough that I realized that I don't much enjoy it. IMHO, both C++ and Rust feel too much like puzzle solving ("how do I solve this prob…

Maybe we just work on different kinds of software, but I feel like I'm actually solving problems in Rust when I'm using it. I don't have to think about all the terrible string manipulation APIs and how they can come back and bite me, who owns what is something I still have to decide except that the compiler actually helps out, and I have access to nice APIs that solve ancillary problems for me already (e.g., rayon, s…

> terrible string manipulation APIs

Don't use (most of) the C stdlib, it's useless and hopelessly antiquated (not just for string manipulation), instead use 3rd party libs.

> who owns what is something I still have to decide except that the compiler actually helps out

Lifetime management for dynamically allocated memory in C should also be wrapped in libraries and not left to the library user. In general, well designed C library APIs replace "high level abstractions" in other languages.

But I agree, the memory safety aspect of Rust is great, and I'd love a small language similar to C, but with a Rust-like borrow checker (but without all the stdlib bells'n'whistles that come with it, like Box, RefCell, Rc, Arc, etc etc etc...) - instead such a language should try to discourage the user from complex dynamic memory management scenarios in the first place.

It's not the memory safety in Rust that turns me off, but the rest of the 'kitchen sink' (for instance the heavy functional-programming influence).

Re: C23 Implications for C Libraries

#94

Post by Mindless2112 »

flohofwoe wrote: post #58
vbtemp wrote: post #44

I have a question I've always wanted to know but too embarrassed to ask (Especially because I've extensively used C for well over a decade now and am intimately familiar with it): Who exactly are these new C-standards for? I interact and use C on an almost daily basis. But almost always ANSI C (and sometimes C99). This is because every platform, architecture, etc has at least an ANSI C compiler in common so it serves…

In my case: because writing C code (specifically C99 or later - designated init and compound literals!) gives me joy in a way that neither C++ nor Rust provide (C++ was my go-to language for nearly two decade between ca. 1998 and 2017), and I tinkered with Rust a couple of years ago, enough that I realized that I don't much enjoy it. IMHO, both C++ and Rust feel too much like puzzle solving ("how do I solve this prob…

In contrast, when I write C, I spend far too much time thinking "how do I solve this problem without causing undefined behavior?"

Re: C23 Implications for C Libraries

#95

Post by flohofwoe »

Mindless2112 wrote: post #94
flohofwoe wrote: post #58

Earlier quoted context omitted.

In my case: because writing C code (specifically C99 or later - designated init and compound literals!) gives me joy in a way that neither C++ nor Rust provide (C++ was my go-to language for nearly two decade between ca. 1998 and 2017), and I tinkered with Rust a couple of years ago, enough that I realized that I don't much enjoy it. IMHO, both C++ and Rust feel too much like puzzle solving ("how do I solve this prob…

In contrast, when I write C, I spend far too much time thinking "how do I solve this problem without causing undefined behavior?"

That what UBSAN is for (along with ASAN, TSAN, static analyzers and compiler warnings, just dial everything to eleven and you can offload a lot of that thinking to the compiler - it's not the 1990's anymore ;)

Re: C23 Implications for C Libraries

#96

Post by mathstuf »

flohofwoe wrote: post #93
mathstuf wrote: post #89

Earlier quoted context omitted.

Maybe we just work on different kinds of software, but I feel like I'm actually solving problems in Rust when I'm using it. I don't have to think about all the terrible string manipulation APIs and how they can come back and bite me, who owns what is something I still have to decide except that the compiler actually helps out, and I have access to nice APIs that solve ancillary problems for me already (e.g., rayon, s…

> terrible string manipulation APIs Don't use (most of) the C stdlib, it's useless and hopelessly antiquated (not just for string manipulation), instead use 3rd party libs. > who owns what is something I still have to decide except that the compiler actually helps out Lifetime management for dynamically allocated memory in C should also be wrapped in libraries and not left to the library user. In general, well design…

> use 3rd party libs

And now I have more problems ;) . (And I develop on CMake; consistently using external deps is a nightmare.)

The thing is that I usually am that library author (or working in an area that acts like that).

I'm not sure what you expect to be left if you say "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles").

I also really enjoy the functional aspects. I don't want to think about what some of the iterator-based code I've done looks like in C or C++ (even with ranges).

Re: C23 Implications for C Libraries

#97

Post by Mindless2112 »

flohofwoe wrote: post #95
Mindless2112 wrote: post #94

Earlier quoted context omitted.

In contrast, when I write C, I spend far too much time thinking "how do I solve this problem without causing undefined behavior?"

That what UBSAN is for (along with ASAN, TSAN, static analyzers and compiler warnings, just dial everything to eleven and you can offload a lot of that thinking to the compiler - it's not the 1990's anymore ;)

UB sanitizers can only show that your code has undefined behavior, not that it does not. And the results are only as good as your tests. Those sanitizers are also not available with old embedded toolchains.

I do dial up the warnings to 11, yet it is not enough.

I've written C code that's currently running on hardware orbiting the earth. I'll never do it again if I can help it; it wasn't worth the stress. You only get one chance to get it right.

Re: C23 Implications for C Libraries

#98

Post by flohofwoe »

Mindless2112 wrote: post #97
flohofwoe wrote: post #95

Earlier quoted context omitted.

That what UBSAN is for (along with ASAN, TSAN, static analyzers and compiler warnings, just dial everything to eleven and you can offload a lot of that thinking to the compiler - it's not the 1990's anymore ;)

UB sanitizers can only show that your code has undefined behavior, not that it does not. And the results are only as good as your tests. Those sanitizers are also not available with old embedded toolchains. I do dial up the warnings to 11, yet it is not enough. I've written C code that's currently running on hardware orbiting the earth. I'll never do it again if I can help it; it wasn't worth the stress. You only get…

> I've written C code that's currently running on hardware orbiting the earth.

I guess in such a situation I would not not trust any compiler (for any programming language), no matter how 'safe' it claims to be, but instead carefully audit and test every single assembly instruction in the compiler output ;)

Re: C23 Implications for C Libraries

#99

Post by flohofwoe »

mathstuf wrote: post #96
flohofwoe wrote: post #93

Earlier quoted context omitted.

> terrible string manipulation APIs Don't use (most of) the C stdlib, it's useless and hopelessly antiquated (not just for string manipulation), instead use 3rd party libs. > who owns what is something I still have to decide except that the compiler actually helps out Lifetime management for dynamically allocated memory in C should also be wrapped in libraries and not left to the library user. In general, well design…

> use 3rd party libs And now I have more problems ;) . (And I develop on CMake; consistently using external deps is a nightmare.) The thing is that I usually am that library author (or working in an area that acts like that). I'm not sure what you expect to be left if you say "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles"). I also really enjoy the f…

> "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles")

Not what I meant, heap allocations are allowed (although the stack should be preferred if possible), but ideally only with long lifetimes and stable locations (e.g. pre-allocated at program startup, and alive until the program shuts down), and you need a robust solution for spatial and temporal memory safety, like generation-counted index handles: https://floooh.github.io/2018/06/17/handles-vs-pointers.html).

Re: C23 Implications for C Libraries

#100

Post by torstenvl »

vbtemp wrote: post #44

I have a question I've always wanted to know but too embarrassed to ask (Especially because I've extensively used C for well over a decade now and am intimately familiar with it): Who exactly are these new C-standards for? I interact and use C on an almost daily basis. But almost always ANSI C (and sometimes C99). This is because every platform, architecture, etc has at least an ANSI C compiler in common so it serves…

One thing I'm really looking forward to is standardization of binary literals. Bitwise masking makes a lot more sense with binary literals than hex literals.

Example:

https://pasteboard.co/VkjrJIOZzaiR.jpg

(Sorry for pasting code as an image, I'm on my phone)

Post reply on HN