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

51–60 of 135 posts

Re: C23 Implications for C Libraries

#51

Post by acuozzo »

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…

> Who exactly are these new C-standards for?

An example: The C11 memory model + + many compilers supporting C11 has/had a positive impact on language runtimes. Portable CAS!

> If your team is up-to-date enough to quickly adopt C23, then why not just use Rust or (heaven forbid, C++23)?

Another example: If you're programming e.g. non-internet-connected atomic clocks with weather sensors like those produced by La Crosse, then there's no real security model to define, so retraining an entire team to use Rust wouldn't make much sense. (And, yes, I know that Rust brings with it more than just memory safety, but the semantic overhead comes at a cost.)

Another example: Writing the firmware to drive an ADC and broker communication with an OS driver.

Another example: The next Furby!

Re: C23 Implications for C Libraries

#52

Post by brandmeyer »

zxwrt wrote: post #21

Sad that C23 didn't get symbol visibility attributes. They are very useful for libraries. Perhaps there is still a chance to get them?

Not surprising, though. The issues surrounding if/how a system provides libraries of any kind (static or shared) are completely implementation-defined. The Standard doesn't have anything to say about them at all except for the program-wide symbol scope rules.

Re: C23 Implications for C Libraries

#53

Post by amag »

Joker_vD wrote: post #39
formerly_proven wrote: post #35

Earlier quoted context omitted.

int -> intpro_t -> intmax_t -> intultra_t

And then there is intpremium_t which is required to be somewhere between intpro_t and intultra_t but has no relation to intmax_t, just for some additional fun.

intpremium_t is only available to paying ANSI-members.

Re: C23 Implications for C Libraries

#54

Post by avar »

AnssiH wrote: post #40
avar wrote: post #32

Earlier quoted context omitted.

So, a "what your mother didn't tell you about C standardization!". I.e. that some popular compilers flaunted the standard, as wider and supported integers should surely have been "[u]intmax_t". And now code written to conform with the intent and wording of C99 will need to change?

No, the ABI issue is fundamentally there regardless of what compilers did or didn't do. If you have an interface that has a function that e.g. takes an intmax_t parameter (and even the C standard has those, e.g. imaxabs()), increasing intmax_t size (ABI change) would break existing callers. So you can only change intmax_t size if you do not care about ABI stability.

Exactly, and the way "intmax_t" was previously defined in C99 implied that you needed to break that ABI compatibility if you introduced larger integer types.

Re: C23 Implications for C Libraries

#55

Post by aidenn0 »

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…

Places that are just now adopting C11 will probably adopt C23 in 12 years? C++ is (unfortunately, IMO) making inroads into embedded, but C is also still pretty widely used.

Re: C23 Implications for C Libraries

#56

Post by gavinhoward »

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 also a C developer, but I do use the more modern versions.

There are four big reasons why:

* Atomics. These are the biggest missing feature in older C.

* Static asserts. I can't tell you how much I love being able to put in a static assert to ensure that my code doesn't compile if I forget to update things. For example, I'll often have static constant arrays tied to the values in an enum. If I update the enum, I want my code to refuse to compile until I update the array. I have 20 instances of static asserts in my current project.

* `max_align_t`. It's super useful to have a type that has the maximum alignment possible on the architecture.

* `alignof()` and friends. It's super useful to get the alignment of various types. Combined with `max_align_t`, it is actually possible to safely write allocators in C. Previously, it wasn't really possible to do safely or portably. And I have at least three allocators in my current project.

You're right that C11 doesn't have nearly the reach the ANSI C does, but it does have slightly more than Rust, much more if you consider Rust's tier 3 support to be iffy, which I do.

And it does have one HUGE advantage against Rust: compile times. On my 16-core machine, I can do a full rebuild in 2.5 seconds. If I changed one file in Rust, it might take that long just to compile that one file.

That's not to say Rust is without advantages; one of my allocators is designed to give me as much of Rust's borrow checker as possible, on top of API's designed around that fact.

tl;dr: I use modern C for a few features not found in C89, for the slightly better platform support against Rust, and for the fast compiles.

Re: C23 Implications for C Libraries

#57

Post by zozbot234 »

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…

C provides the only stable ABI for Rust, and changes to the C++ ABI may also occur in the future. So the implications of new C standards for library code are especially relevant.

Re: C23 Implications for C Libraries

#58

Post by flohofwoe »

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 problem in *C++*" or "how do I solve this problem in *Rust*?"), when writing C code, the programming language disappears and it simply becomes "how do I solve this problem?").

PS: I agree that the C standard isn't all that relevant in practice though, you still need to build and test your code across the relevant compilers.

Re: C23 Implications for C Libraries

#59

Post by davidtgoldblatt »

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…

My usages are similar to yours, but new C standards still benefit me because I can opportunistically detect and make use of new features in a configure script.

To use my baby as an example: free_sized(void *ptr, size_t alloc_size) is new in C23. I can detect whether or not it's available and use it if so. If it's not available, I can just fall back to free() and get the same semantics, at some performance or safety cost.

Re: C23 Implications for C Libraries

#60

Post by fulafel »

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…

Old software is very slow and expensive to change. Adopting a new C version doesn't need a failure prone expensive synchronized collective-action rewrite throughout your sectors supply chain, new tooling, platform runtime ports, etc. Rust would.
Post reply on HN