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

81–90 of 135 posts

Re: C23 Implications for C Libraries

#81

Post by kllrnohj »

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.

No, you misunderstand. Wide contacts are not universally superior to narrow ones, and more often than not narrow contacts catch more bugs than wide ones do.

For example almost never does a programmer want int to rollover in a for loop. Defining that behavior doesn't help, and indeed makes tools like linters or sanitizers less useful.

Re: C23 Implications for C Libraries

#82

Post by kllrnohj »

rwmj wrote: post #24
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?

I suppose because they are an ELF feature rather than a language feature? Anyway you can (and should!) use -fvisibility=hidden and add __attribute__((__visibility__("default"))) to public symbols when writing a C library. It will make calls between non-visible symbols faster because the compiler doesn't have to generate code to handle ELF symbol interposition.

You can (and should!) use a linker version script instead to ensure you're not accidentally leaking any exported symbols from other static library dependencies ;)

Re: C23 Implications for C Libraries

#84

Post by sigsev_251 »

pjmlp wrote: post #48
cesarb wrote: post #36

Earlier quoted context omitted.

It's great news unless you're maintaining software which defines its own version of these three keywords (which was necessary before C99, and AFAIK there is a popular C compiler which still doesn't have full support for C99). And until everyone moves to C23 (which will probably take a very long time; a quick web search tells me that it took until 2015 for the aforementioned popular C compiler to add support for the C…

If you mean MVSC, it never will, because it now supports C11 and C17, minus the optional annexes from C99 that were dropped in C11, and atomics aren't fully supported as well.

I've heard that they are working on C11 atomics, now that the C++ standard includes for compatibility with C.

Re: C23 Implications for C Libraries

#85

Post by fweimer »

attractivechaos wrote: post #73
acuozzo wrote: post #51

Earlier quoted context omitted.

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

Atomic is one of the few things in C11 I like most. Unfortunately, it is an optional feature along with threading [1]. It is not portable. In the end, I am still using gcc/clang's __sync or __atomic builtins. [1] https://en.wikipedia.org/wiki/C11_(C_standard_revision)#Opti...

is provided by GCC (not the libc), so I expect it to be available everywhere the atomic builtins are supported.

I prefer the builtins. With _Atomic you can easily get seq-cst behavior by mistake, and the interfaces are strictly speaking only valid for _Atomic types.

Re: C23 Implications for C Libraries

#86

Post by vbtemp »

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…

That's very interesting. Thank you.

Re: C23 Implications for C Libraries

#87

Post by fweimer »

layer8 wrote: post #47
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…

Existing C code needs to be maintained, and can take advantage of the newer features when available in the compiler. The Linux kernel is moving to C11, and may move to C17/C23 later. Also not everyone wants to put up with the compilation times, object sizes, and aesthetics of Rust. As for new developments, see for example https://news.ycombinator.com/item?id=33675462 which uses C11.

I doubt that the kernel will adopt the C++ memory model (the big change in C11). Instead, they will keep doing their own thing. Given the problems with the memory model, I can't really fault them. But framing this in terms of standards versions is a bit of a stretch. They could easily adopt additional GCC extensions over time as they move minimum compiler versions forward. Standardization does not really matter there.

Re: C23 Implications for C Libraries

#88

Post by kazinator »

acuozzo wrote: post #51
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…

Requiring C11 is itself a portability issue.

I can easily whip up CAS for all platforms I care about, plus a few more for bonus, using nothing but C99 or C90 (and have actually done it before).

Possibly, without even using any language extensions, unless I want the operations inlined.

Re: C23 Implications for C Libraries

#89

Post by mathstuf »

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…

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, serde, etc.). I can't wait for the day when another parser will never be written in C again.

In C, I feel like I'm building a house out of tinker toys, C++ is Lego Techniks, and Rust I'm using bricks and mortar. FWIW, Python feels like waterballoons and drywall to me; while it might look OK from the outside, one thing pierces your exterior and things tend to sag sadly from there.

Re: C23 Implications for C Libraries

#90

Post by fweimer »

davidtgoldblatt wrote: post #59
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 c…

The free_sized function is kind of a bad example, though. For years to come, using free_sized will break malloc interposition. Interposed mallocs will not support free_sized initially. (It's currently not in jemalloc, tcmalloc, mimalloc as far as I can see.) If we add it to glibc and your application picks it up, calls to free_sized will end up with the glibc allocator even if malloc/free/… have been interposed. Maybe there is a way to paper over this in the glibc implementation of free_sized (rather than calling free unconditionally), and still do something useful for the glibc allocator. I don't know.
Post reply on HN