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

61–70 of 135 posts

Re: C23 Implications for C Libraries

#61

Post by jrmg »

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…

Outside our bubble, there’s an _ocean_ of embedded software/firmware and lower level library stuff, on up-to-date platforms, written in C by people or teams that would find switching to Rust just a _massive_ chore. I’d guess there is at least an order of magnitude more of this than Rust.

And I certainly appreciated C11 when writing Objective-C, so I’m sure people with large codebases of ObjC will appreciate it (though most will be using Swift for new features nowadays).

Re: C23 Implications for C Libraries

#62

Post by ElevenLathe »

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.

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.

Re: C23 Implications for C Libraries

#63

Post by loeg »

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…

Technically, it would break ABIs. I agree, they should have just broken any ABI relying on intmax_t and made it definitionally unstable (instead of making it useless, which they've chosen to do instead).

Re: C23 Implications for C Libraries

#64

Post by loeg »

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.

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

Re: C23 Implications for C Libraries

#65

Post by addaon »

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 do for Rust. 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, and the cost of qualifying a new language's toolchain would be absurd. For this reason, C has a long, long future as one of the few languages (along with Ada, where some folk are making a real investment in tool qualification) for critical code; and even if it takes a decade for C23 features to stabilize and make it to this population, well, we'll still be writing C code well beyond '33.

Re: C23 Implications for C Libraries

#66

Post by Bhurn00985 »

davidtgoldblatt wrote: post #59
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…

My usages are similar to yours, but new C standards still benefit me because I can opportunistically detect and make use of new features in a configure script. To use my baby as an example: free_sized(void *ptr, size_t alloc_size) is new in C23. I can detect whether or not it's available and use it if so. If it's not available, I can just fall back to free() and get the same semantics, at some performance or safety c…

I don't fully understand the need or benefit of having free_sized() available tbh.

Spec says it's functionally equivalent to free(ptr) or undefined:

If ptr is a null pointer or the result obtained from a call to malloc, realloc, or calloc, where size size is equal to the requested allocation size, this function is equivalent to free(ptr). Otherwise, the behavior is undefined

Even the recommended practice does not really clarify things:

Implementations may provide extensions to query the usable size of an allocation, or to determine the usable size of the allocation that would result if a request for some other size were to succeed. Such implementations should allow passing the resulting usable size as the size parameter, and provide functionality equivalent to free in such cases

When would someone use this instead of simply free(ptr) ?

Re: C23 Implications for C Libraries

#67

Post by enriquto »

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…

> Who exactly are these new C-standards for?

For me and for many colleagues in my lab? C is quite big in scientific computing and signal processing. Fortran would be slightly better, and it is widely used, but not directly around me. The C99 standard, which added complex numbers and variable length arrays, was truly a godsend in the field. I cannot imagine working without it.

If you write a numerical algorithm that needs to be run 15 years from now, then C and Fortran are possibly the sanest choices. If you do something in other, fancier, languages, you can be sure that your code will stop working in a few years.

The new C standards are really minor changes to the language, and they happen in the span of a decade. It is quite easy to be up to date. And in the rare case that your old code stops compiling, the previous (less than a handful) versions of the language are all readily available as compiler options in all compilers. You can be reasonably sure that a C program written today will still compile and run in 20 years. You can be 100% sure that a python+numpy program won't. If you care about this (for example, if you are writing a new linear algebra algorithm to factor matrices), then choosing C is a rational, natural choice.

Re: C23 Implications for C Libraries

#68

Post by quelsolaar »

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

Re: C23 Implications for C Libraries

#69

Post by pwdisswordfish9 »

ElevenLathe wrote: post #62
layer8 wrote: post #50

Earlier quoted context omitted.

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.

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.

Slower-and-probably-not-what-the-programmer-meant-either code.

Re: C23 Implications for C Libraries

#70

Post by pwdisswordfish9 »

Joker_vD wrote: post #39
formerly_proven wrote: post #35

Earlier quoted context omitted.

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.

    typedef int intpremium_mediocre_t;
Post reply on HN