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

131–135 of 135 posts

Re: C23 Implications for C Libraries

#131

Post by avar »

gpderetta wrote: post #78
avar wrote: post #54

Earlier quoted context omitted.

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.

Are you saying that the standard should attempt to impose requirements to non-conforming compiler modes? How would that even work?

I'm saying that if you wrote conforming C99 code that made the assumptions C99 guaranteed your code will be subtly broken by C23. Whether that was a worthwhile trade-off is another matter.

Re: C23 Implications for C Libraries

#132

Post by stephencanon »

loeg wrote: post #64
layer8 wrote: post #45

Earlier quoted context omitted.

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.

They could have retroactively made intmax_t that type. Anyone using intmax_t in ABIs can keep using C11 until they fix their ABIs.

C uses intmax_t in its ABI. I’m all for deprecating those ABI, because they’re crap, but the C committee doesn’t see it that way.

Re: C23 Implications for C Libraries

#133

Post by Gibbon1 »

a1369209993 wrote: post #118
layer8 wrote: post #45

Earlier quoted context omitted.

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.

That doesn't work because possibly[2] the most important single use of uintmax_t is the printf specifier "%ju", ie a ABI boundary. Ironically, this is actually one of the only[0] legitimate uses for standard[1] PRI* macros, since that could expand to whichever of "%llu", "%w128u", etc, was appropriate to the caller. 0: And I'm not sure "one of" is actually needed. 1: as opposed to nonstandard ones like PRIu_xlib_atom…

I'd argue that printf and va_args are terrible and should have been depreciated 25 years ago.

Re: C23 Implications for C Libraries

#134

Post by dang »

pwdisswordfish9 wrote: post #70
Joker_vD wrote: post #39

Earlier quoted context omitted.

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.

typedef int intpremium_mediocre_t;

I need to ask you a couple things. (This is not particularly a response to the current comment - I just need a recent place to post this.)

First, please stop breaking the site guidelines. You've repeatedly posted unsubstantive/flamebait comments—which as you know, that is not what HN is for. In particular, we ban accounts that do abusive things like https://news.ycombinator.com/item?id=33617059.

Second, please stop routinely creating accounts. As the guidelines say, Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

https://news.ycombinator.com/newsguidelines.html

Re: C23 Implications for C Libraries

#135

Post by gpderetta »

avar wrote: post #131
gpderetta wrote: post #78

Earlier quoted context omitted.

Are you saying that the standard should attempt to impose requirements to non-conforming compiler modes? How would that even work?

I'm saying that if you wrote conforming C99 code that made the assumptions C99 guaranteed your code will be subtly broken by C23. Whether that was a worthwhile trade-off is another matter.

To be fair C23 is simply standardising the status quo. There is no point in having a standard if nobody implements it.
Post reply on HN