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

111–120 of 135 posts

Re: C23 Implications for C Libraries

#111

Post by quelsolaar »

kazinator wrote: post #92
quelsolaar wrote: post #68

Earlier quoted context omitted.

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…

> compiler developers back port it in to older versions of C where it was simply unclear You cannot rely on that. If you're maintaining C90 code, with a C90 compiler or compilation mode, you should go by what is written ISO 9899:1990, plus whatever the platform itself documents. We actually don't want compiler writers mucking with the support for older dialects to try to modernize it. It's a backward-compatibility fe…

C cares a hell of a lot about backwards compatibility. Whenever there is a corner case that gets fixed, the number one goal is to retain compatibility. most of the time, these clarifications clarify what everyone is already doing and has been doing for decades.

Also, most of these corner cases are so obscure that the vast majority of people with decades of C experience have not encountered them. C is an extremely explored space.

Re: C23 Implications for C Libraries

#112

Post by vbtemp »

MaxBarraclough wrote: post #110
kazinator wrote: post #88

Earlier quoted context omitted.

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.

Did you manage to write a truly portable compare-and-swap in standard C? Or did the code just happen to seem to work on your platform? I'd be surprised if the former were possible. From a quick web search, C doesn't even give you the guarantees necessary for Peterson's Algorithm, [0][1] and volatile doesn't help. [2][3] [0] https://codereview.stackexchange.com/a/124683 [1] https://stackoverflow.com/questions/35527557…

I think the point by kazinator still stands. C11 is still a portability issue (which was the root of my original question above). ANSI C is the de-facto baseline everything has in common, using C11+ narrows which platforms you're able to build for. Even if C11 does provide the primitives for correct implementation of Peterson's Algorithm, what about the other platforms that don't have a C11 compiler - it does them no good. As to the point more directly, a lot of the C code I've seen is for real time and embedded systems that are usually time and memory partitioned, and do not have the same concerns regarding concurrency.

I guess if I could rephrase my original question: People who are going to adopt C23 - who are you and what field/industry/line-of-work are you in?

Asking because in my line-of-work, C is ubiquitous and I personally love coding in C, but anything beyond ANSI C (or C99) is "cool" but undermines the point of C as I've used it, which is its use cross-platform for a huge set of common and uncommon architectures and instruction sets. If something only needs to run on common, conventional platforms, C, however much I love it, would no longer necessarily be a strong contender in light of many alternatives. It seems like these standards target an ever shrinking audience (much smaller than the whole universe of software developers working in C).

Re: C23 Implications for C Libraries

#113

Post by steveklabnik »

flohofwoe wrote: post #93
mathstuf wrote: post #89

Earlier quoted context omitted.

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

> terrible string manipulation APIs Don't use (most of) the C stdlib, it's useless and hopelessly antiquated (not just for string manipulation), instead use 3rd party libs. > who owns what is something I still have to decide except that the compiler actually helps out Lifetime management for dynamically allocated memory in C should also be wrapped in libraries and not left to the library user. In general, well design…

What is your favorite 3rd party string library? I'm aware of several, but haven't used any of them in anger.

Re: C23 Implications for C Libraries

#114

Post by ghoward »

fweimer wrote: post #103
gavinhoward wrote: post #56

Earlier quoted context omitted.

I'm also a C developer, but I do use the more modern versions. There are four big reasons why: * Atomics. These are the biggest missing feature in older C. * Static asserts. I can't tell you how much I love being able to put in a static assert to ensure that my code doesn't compile if I forget to update things. For example, I'll often have static constant arrays tied to the values in an enum. If I update the enum, I…

Except for max_align_t (which is broken even for scalar types on some targets, and doesn't help with vector types by design), all these things were available long before standardization. So I'm not sure if this is a compelling argument for standardization.

Without standardization, I have to rely on specific compilers. That's not great, either.

Re: C23 Implications for C Libraries

#115

Post by kazinator »

MaxBarraclough wrote: post #110
kazinator wrote: post #88

Earlier quoted context omitted.

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.

Did you manage to write a truly portable compare-and-swap in standard C? Or did the code just happen to seem to work on your platform? I'd be surprised if the former were possible. From a quick web search, C doesn't even give you the guarantees necessary for Peterson's Algorithm, [0][1] and volatile doesn't help. [2][3] [0] https://codereview.stackexchange.com/a/124683 [1] https://stackoverflow.com/questions/35527557…

Neither. The code wasn't standard C, and it didn't just "happen" to work, either.

You probably wouldn't want to build an atomic compare-exchange in standard C, even if it were possible; you find out what the hardware provides and work with that.

Re: C23 Implications for C Libraries

#116

Post by a1369209993 »

dzaima wrote: post #91
ElevenLathe wrote: post #62

Earlier quoted context omitted.

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.

If you do "for (int i = 0; i While two's complement signed rollover can be pretty useful, in 99% of cases you don't need it, and casting to unsigned for the 1% is a worthwhile sacrifice for the better optimizations for the common case, and it'll be pretty clear when you want wrapping or not (and sanitizers will be able to keep reporting signed overflow as errors without false positives).

No, my 'intent' is to get:

  error: signed integer variable used as array index (-Wsigned-index)
  `int i`: should be `size_t i`
  error: comparison of signed to unsigned integer (-Wsigned-comparison)
  `i
Scare quotes on "intent", because I don't write (that particular kind of) obviously broken code in the first place, but the upshot is that i and len both need to be size_t, and anything that lets the compiler obscure that is de facto bad.

Edit: previously assumed len was wrong too, but on rereading, you were implying len was already the correct type, and only i was wrong.

(Also, the word "variable" is significant; IIRC something like 5+bytecode_next_char promotes to int, but can't actually be negative[1] so shouldn't generate a warning.)

1: Assuming the compiler is configured correctly, ie char is unsigned.

Re: C23 Implications for C Libraries

#117

Post by MaxBarraclough »

kazinator wrote: post #115
MaxBarraclough wrote: post #110

Earlier quoted context omitted.

Did you manage to write a truly portable compare-and-swap in standard C? Or did the code just happen to seem to work on your platform? I'd be surprised if the former were possible. From a quick web search, C doesn't even give you the guarantees necessary for Peterson's Algorithm, [0][1] and volatile doesn't help. [2][3] [0] https://codereview.stackexchange.com/a/124683 [1] https://stackoverflow.com/questions/35527557…

Neither. The code wasn't standard C, and it didn't just "happen" to work, either. You probably wouldn't want to build an atomic compare-exchange in standard C, even if it were possible; you find out what the hardware provides and work with that.

  > The code wasn't standard C, and it didn't just "happen" to work
Thanks, that makes sense.

At the risk of sounding pedantic, you did say using nothing but C99 or C90, implying use of standard features only.

  > You probably wouldn't want to build an atomic compare-exchange in
  > standard C, even if it were possible; you find out what the
  > hardware provides and work with that.
Agreed.

Re: C23 Implications for C Libraries

#118

Post by a1369209993 »

layer8 wrote: post #45
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).

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 or the like

2: Depending on how you define "single", it competes with (x*(uintmax_t)y)>>UINTPTR_BIT, but that's not actually reliable since uintmax_t isn't (IIRC) guaranteed to be larger than uintptr_t.

Re: C23 Implications for C Libraries

#119

Post by MaxBarraclough »

vbtemp wrote: post #112
MaxBarraclough wrote: post #110

Earlier quoted context omitted.

Did you manage to write a truly portable compare-and-swap in standard C? Or did the code just happen to seem to work on your platform? I'd be surprised if the former were possible. From a quick web search, C doesn't even give you the guarantees necessary for Peterson's Algorithm, [0][1] and volatile doesn't help. [2][3] [0] https://codereview.stackexchange.com/a/124683 [1] https://stackoverflow.com/questions/35527557…

I think the point by kazinator still stands. C11 is still a portability issue (which was the root of my original question above). ANSI C is the de-facto baseline everything has in common, using C11+ narrows which platforms you're able to build for. Even if C11 does provide the primitives for correct implementation of Peterson's Algorithm, what about the other platforms that don't have a C11 compiler - it does them no…

  > ANSI C is the de-facto baseline everything has in common,
  > using C11+ narrows which platforms you're able to build for.
Sure, but which platforms are you thinking of? I think you're overestimating the proportion of C codebases that care about targeting highly exotic hardware platforms. GCC can target all sorts of ISAs, including embedded platforms. It can't target, say, the 6502, or PIC, or Z80, but they're small niches.

I'm not an embedded software developer though, perhaps there are more developers using niche C compilers than I realise.

  > Even if C11 does provide the primitives for correct implementation
  > of Peterson's Algorithm, what about the other platforms that don't
  > have a C11 compiler - it does them no good.
If portable atomics/synchronisation machinery is not offered by your C compiler or its libraries, I figure your options are:

1. Use platform-specific atomics/synchronisation functionality

2. Leverage compiler-specific guarantees to write platform-specific atomics/synchronisation functionality, if your compiler offers such guarantees

3. Write your atomics/synchronisation functionality in assembly, and call it from C

Here's a project that uses all 3 approaches. [0] (It's old-school C++ rather than C, but it's the same in principle.)

I'm fairly sure it's not possible to implement your own portable synchronisation primitives in standard-compliant C90 code. As I understand it, the C90 standard has nothing at all to say on concurrency. It's possible that such an attempt might happen to work, on some given platform, but it would be 'correct by coincidence', rather than by definition. (Again, unless the particular compiler guaranteed the necessary properties.)

[0] https://github.com/gogglesguy/fox/blob/fe99324/lib/FXAtomic....

Re: C23 Implications for C Libraries

#120

Post by vbtemp »

MaxBarraclough wrote: post #117
kazinator wrote: post #115

Earlier quoted context omitted.

Neither. The code wasn't standard C, and it didn't just "happen" to work, either. You probably wouldn't want to build an atomic compare-exchange in standard C, even if it were possible; you find out what the hardware provides and work with that.

> The code wasn't standard C, and it didn't just "happen" to work Thanks, that makes sense. At the risk of sounding pedantic, you did say using nothing but C99 or C90 , implying use of standard features only. > You probably wouldn't want to build an atomic compare-exchange in > standard C, even if it were possible; you find out what the > hardware provides and work with that. Agreed.

Interesting discussion, lots of good points all around. Thanks to you both.
Post reply on HN