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

41–50 of 135 posts

Re: C23 Implications for C Libraries

#41

Post by SAI_Peregrinus »

stephencanon wrote: post #23
tpush wrote: post #15

Earlier quoted context omitted.

Presumably because the size of intmax_t was set to something specific on its introduction and changing it now would constitute an ABI break most everywhere.

That’s exactly right. On platforms without ABI stability concerns, there’s no issue, but if you can’t change the ABI intmax_t is stuck being what it’s always been (which is why it was always obviously a bad idea and should not have been included in the standard).

Or include the std version in the name.

intmax_199409L_t for C89's 1994 amendment, etc.

Re: C23 Implications for C Libraries

#42

Post by planede »

account42 wrote: post #31
rwmj wrote: post #24

Earlier quoted context omitted.

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 might also want to compile with -fno-semantic-interposition since no one actually needs semantic interposition for symbols used and defined in the same library so you might es well disable it even or public functions.

And link with the `-Bsymbolic` or `-Bsymbolic-functions` linker options to save on the indirection when calling public functions within the same library but across object files.

Re: C23 Implications for C Libraries

#43

Post by ainar-g »

rwmj wrote: post #3

The page gives a network error. Edit: Ugh, it needs javascript to render simple HTML.

It's especially weird considering that the Markdown file is publicly available:

https://icube-forge.unistra.fr/icps/c23-library/-/blob/main/...

Raw Markdown, for no-JS readers:

https://icube-forge.unistra.fr/icps/c23-library/-/raw/main/R...

Re: C23 Implications for C Libraries

#44

Post by vbtemp »

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 as the least common-denominator to make platform-independent code. As such it also serves as a good target for DSLs as a sort of portable-assembly. But when you don't need that, what's the motivation to use C then? If your team is up-to-date enough to quickly adopt C23, then why not just use Rust or (heaven forbid, C++23)?

I'd love to hear from someone who does actively use "modern" C. I would love to be a "modern C" developer - I just don't and can't see its purpose.

Re: C23 Implications for C Libraries

#45

Post by layer8 »

stephencanon wrote: post #23
tpush wrote: post #15

Earlier quoted context omitted.

Presumably because the size of intmax_t was set to something specific on its introduction and changing it now would constitute an ABI break most everywhere.

That’s exactly right. On platforms without ABI stability concerns, there’s no issue, but if you can’t change the ABI intmax_t is stuck being what it’s always been (which is why it was always obviously a bad idea and should not have been included in the standard).

They could introduce a similar type that is prohibited (checked by the compiler) from occurring in declarations with external linkage (plus some wording regarding casting of data across translation units being undefined behavior for that type). Effectively prohibit it from being used in ABIs. It would then still be useful for intermediate calculations and in macros.

Re: C23 Implications for C Libraries

#46

Post by phkahler »

>> One major change in the language is that two’s complement is now mandatory as a representation for signed types.

This pleases me greatly. Two's complement won decades ago. This also means they could define integer overflow as 2's complement rollover, which is almost universal but is still considered undefined behavior.

Re: C23 Implications for C Libraries

#47

Post by layer8 »

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.

Re: C23 Implications for C Libraries

#48

Post by pjmlp »

cesarb wrote: post #36
ufo wrote: post #28

Earlier quoted context omitted.

Great news! \o/

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.

Re: C23 Implications for C Libraries

#49

Post by electroly »

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…

Are you asking about greenfield development only? One big obvious reason to use C23 instead of Rust or C++23 is if you already have a codebase written in C. Switching to C23 is a compiler flag; switching to Rust is a complete rewrite.

Re: C23 Implications for C Libraries

#50

Post by layer8 »

phkahler wrote: post #46

>> One major change in the language is that two’s complement is now mandatory as a representation for signed types. This pleases me greatly. Two's complement won decades ago. This also means they could define integer overflow as 2's complement rollover, which is almost universal but is still considered undefined behavior.

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.
Post reply on HN