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

101–110 of 135 posts

Re: C23 Implications for C Libraries

#101

Post by mathstuf »

flohofwoe wrote: post #99
mathstuf wrote: post #96

Earlier quoted context omitted.

> use 3rd party libs And now I have more problems ;) . (And I develop on CMake; consistently using external deps is a nightmare.) The thing is that I usually am that library author (or working in an area that acts like that). I'm not sure what you expect to be left if you say "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles"). I also really enjoy the f…

> "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles") Not what I meant, heap allocations are allowed (although the stack should be preferred if possible), but ideally only with long lifetimes and stable locations (e.g. pre-allocated at program startup, and alive until the program shuts down), and you need a robust solution for spatial and temporal memor…

Yeah, I feel like we work in completely different realms of programming. Which is fine; there are plenty of languages out there for all kinds of use cases. FWIW, pre-allocation absolutely doesn't work when you support loading GB-size datasets. You certainly can't leave it sitting around forever either once it is loaded.

Re: C23 Implications for C Libraries

#102

Post by fweimer »

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…

I believe the current WG14 charter is here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm

This text is still in force, it seems:

“ 13. Unlike for C99, the consensus at the London meeting was that there should be no invention, without exception. Only those features that have a history and are in common use by a commercial implementation should be considered. Also there must be care to standardize these features in a way that would make the Standard and the commercial implementation compatible. ”

I read this as saying that anything that gets standardized should be available in one of the major implementations. In practice, most of the qualifying features will have been implemented in both GCC and Clang in the same way, so for most users, there is not much benefit from standardization. Some may feel compelled to support the ”standard” way and the “GCC/Clang” way in the same sources, using a macro, but that isn't much of a win in most cases. Of course, there will be shops that say, “we can't use feature until it's in the standard”, but that never really made sense to me.

Things are considerably murky on the library side. In my experience, library features rarely get standardized in the same way they are already deployed: names change, types change, behavioral requirements are subtly different. (Maybe this is my bias from the library side because I see more such issues.) For programmers, the problem of course is that typical applications do not get exposed to different compiler versions at run time, but it's common for this to happen with the system libraries. This means that the renaming churn that appears to be inherent to standardization causes real problems.

Others have said that new standards are an opportunity to clarify old and ambiguous wording, but in many cases the ambiguity hides unresolved conflict (read: different behavior in existing implementations) in the standardization committee. It's really hard to revise the wording without making things worse, see realloc.

So I'm also not sure what value standardization brings to users of GCC and Clang. Maybe it's different for those who use other compilers. But if standardization is the only way these other vendors implement widely used GCC and Clang extensions (or interfaces common to the major non-embedded C libraries), then the development & support mode for these other implementations does not seem quite right.

Re: C23 Implications for C Libraries

#103

Post by fweimer »

gavinhoward wrote: post #56
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…

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.

Re: C23 Implications for C Libraries

#104

Post by zajio1am »

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.

> This also means they could define integer overflow as 2's complement rollover, which is almost universal but is still considered undefined behavior.

No, they should not. Integer overflow is in most cases logic error, like division by zero or NULL pointer dereference, so it should stay undefined.

Re: C23 Implications for C Libraries

#105

Post by kccqzy »

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…

At least for C++ there is something called defect reports. When agreed, those defect reports to retroactively applied to previously published C++ standards.

As a random example for something as fundamental as classes in C++, the page https://en.cppreference.com/w/cpp/language/classes shows ten defect reports.

Re: C23 Implications for C Libraries

#106

Post by MaxBarraclough »

addaon wrote: post #65
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…

Keep in mind that if you want to write probably-maybe-correct code, Rust is maturing to be able to get you there more easily than C. But if you want actually-correct code, you need to do the legwork regardless of language; and C has a much more mature ecosystem (things like CompCert C, etc) that lets you do much of the analysis portion of that legwork on C code, instead of on generated assembly code as you'd have to…

  > Combined with verification costs that don't vary that much from
  > language to language, and there's a long future where, for
  > safety-critical applications, there's no downside to C -- the cost
  > of verification and analysis swamps the cost of writing the code
That doesn't sound right. You really want to get the code right early on. The later bugs are discovered, the more costly the fix. You may have to restart your testing, for instance.

If the language helps you avoid writing bugs in the first place, that should translate to quicker delivery and lower costs, as well as a reduced probability of bugs making it to production. The Ada folks are understandably keen to emphasise this in their promotional material.

  > the cost of qualifying a new language's toolchain would be absurd
As I understand it, this typically falls to the compiler vendor, not to the people who use the compiler. A compiler vendor targeting safety-critical applications will want to get their compiler certified, e.g. [0]. To my knowledge we're nowhere near a certified Rust compiler, although it seems some folks are trying. [1]

[0] https://www.ghs.com/products/compiler.html

[1] https://ferrous-systems.com/blog/sealed-rust-the-pitch/

Re: C23 Implications for C Libraries

#108

Post by phkahler »

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

So GCC is defining one behavior for overflow in the optimizer (assuming there is no overflow so algebraic expressions can be optimized) and generating code that behaves differently (a+b will wrap around for signed and unsigned types)

That seems suspect to me but I understand why they'd do it.

Re: C23 Implications for C Libraries

#109

Post by pantry-man »

zajio1am wrote: post #104
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.

> This also means they could define integer overflow as 2's complement rollover, which is almost universal but is still considered undefined behavior. No, they should not. Integer overflow is in most cases logic error, like division by zero or NULL pointer dereference, so it should stay undefined.

It can still be well defined behaviour and still an error

Re: C23 Implications for C Libraries

#110

Post by MaxBarraclough »

kazinator wrote: post #88
acuozzo wrote: post #51

Earlier quoted context omitted.

> Who exactly are these new C-standards for? An example: The C11 memory model + + many compilers supporting C11 has/had a positive impact on language runtimes. Portable CAS! > If your team is up-to-date enough to quickly adopt C23, then why not just use Rust or (heaven forbid, C++23)? Another example: If you're programming e.g. non-internet-connected atomic clocks with weather sensors like those produced by La Crosse…

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/errors-with-pet...

[2] https://web.archive.org/web/20160525000152/https://software....

[3] https://old.reddit.com/r/programming/comments/d457c/volatile...

Post reply on HN