Sad that C23 didn't get symbol visibility attributes. They are very useful for libraries. Perhaps there is still a chance to get them?
C23 Implications for C Libraries
21–30 of 135 posts
Re: C23 Implications for C Libraries
#22Why is stdbool.h deemed "mostly useless now"? Is it always available via another header now?
In C23, `bool`, `true` and `false` are available without including `stdbool.h`.
Re: C23 Implications for C Libraries
#23"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.
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).
Re: C23 Implications for C Libraries
#24Sad 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.
Re: C23 Implications for C Libraries
#25"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.
Also a 128 bit intmax_t would be slower and the 128 bit extensions are used only rarely.
Re: C23 Implications for C Libraries
#26Earlier 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).
No problem, just introduce intreallymax_t and later intmaxthistimewereallymeanit_t.
Re: C23 Implications for C Libraries
#27Sad 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.
These are non-standard GNU extensions, unfortunately.
Re: C23 Implications for C Libraries
#28Re: C23 Implications for C Libraries
#29Earlier quoted context omitted.
Why? They seem pretty harmless, are they difficult to implement?
They’re not difficult to implement. It’s a sed pass running before any preprocessor or even lexer, which is the horrifying thing. They replace characters in source code, they’re not normal tokens like digraphs. And so e.g. the following program won’t print what a mere mortal would expect: #include int main() { puts(“What??(Really.)”); } Try running that. Only change the quote marks to the ones on a normal keyboard (I…
or put the code into godbolt and take a look at the strings with -std=C11 and without
https://godbolt.org/z/zn44rdW6P
Re: C23 Implications for C Libraries
#30Earlier quoted context omitted.
The standard itself has a better example (well, older versions). In C99 it's: printf("Eh???/n"); Which is the same as: printf("Eh?\n"); I.e. the "??/" supplies the "\" to the "n", making it a "\n". I think it's good that they're gone (they were there to support some ancient non-ASCII systems). But it's worth mentioning that the "horrifying" semantics are there so that these trigraphs combine with digraphs (edit: "esc…
This example doesn’t involve digraphs. Trigraphs also preceded digraphs, so their semantics couldn’t have been motivated by digraphs. In fact digraphs were added as a better-thought-out alternative to trigraphs. Digraphs were added in C99, whereas trigraphs were added in C89.
Sorry, you're completely right. I had digraphs confused with character-constant escape sequences (as defined in "6.4.4.4" in C99).
I.e. that the trigraphs need to be parsed like that both because they're replacements for basic syntax like "{" and "}", but also because they need to be considered as if though the parser saw a "\" in a constant, as they next character may be e.g. "n", forming a "\n", not "\\n".