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

31–40 of 135 posts

Re: C23 Implications for C Libraries

#31

Post by account42 »

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

Re: C23 Implications for C Libraries

#32

Post by avar »

tpush wrote: post #15
avar wrote: post #9

"Extended integer types may be wider than intmax_t". I'm sure there's a good reason for this, but it was introduced in C99, which says (in 7.8.1.5): "[intmax_t] designates a signed integer type capable of representing any value of any signed integer type". That was already portable between 16 bit, 32 bit, 64 bit etc. Why is it that just because the compiler supports 128 bit or 256 bit integers that compiling in such…

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.

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?

Re: C23 Implications for C Libraries

#33

Post by account42 »

zxwrt wrote: post #27
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.

These are non-standard GNU extensions, unfortunately.

All compiler flags are non-standard because the C standard does not concern itself with them at all.

That said, there are effectively two standard compiler interfaces: MSVC and GCC and everyone else emulates one or both of these.

Similarily, symbol visibility is not something that the C standard cares about because it doesn't even care about libraries in the first place. Again, for all platforms that have symbol visibility (e.g. PE and ELF based ones, although the details differ) there is a defacto standard for the compiler flags and attributes to control the visilibity: the MSVC and GCC extensions.

Re: C23 Implications for C Libraries

#35

Post by formerly_proven »

codeflo wrote: post #26
stephencanon wrote: post #23

Earlier quoted context omitted.

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).

No problem, just introduce intreallymax_t and later intmaxthistimewereallymeanit_t.

int -> intpro_t -> intmax_t -> intultra_t

Re: C23 Implications for C Libraries

#36

Post by cesarb »

ufo wrote: post #28
pdw wrote: post #22

Earlier quoted context omitted.

In C23, `bool`, `true` and `false` are available without including `stdbool.h`.

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 C99 stdbool.h header), all C projects will still have to include that header.

Re: C23 Implications for C Libraries

#38

Post by zxwrt »

account42 wrote: post #33
zxwrt wrote: post #27

Earlier quoted context omitted.

These are non-standard GNU extensions, unfortunately.

All compiler flags are non-standard because the C standard does not concern itself with them at all. That said, there are effectively two standard compiler interfaces: MSVC and GCC and everyone else emulates one or both of these. Similarily, symbol visibility is not something that the C standard cares about because it doesn't even care about libraries in the first place. Again, for all platforms that have symbol visi…

Actually, the only compiler interface that can claim to call itself a standard is POSIX c99. Everything else is too volatile to be a standard.

Re: C23 Implications for C Libraries

#39

Post by Joker_vD »

formerly_proven wrote: post #35
codeflo wrote: post #26

Earlier quoted context omitted.

No problem, just introduce intreallymax_t and later intmaxthistimewereallymeanit_t.

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.

Re: C23 Implications for C Libraries

#40

Post by AnssiH »

avar wrote: post #32
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.

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.

Post reply on HN