> What does c17 add exactly, more C++-ish bullshit or not?

Multithreading support and such (atomics, thread-local storage and a guarantee that `errno` is in TLS), explicitly aligned types and allocations, dedicated types for strings known to be Unicode, _Noreturn, _Generic, _Static_assert, anonymous structs and unions in the nested position, quick_exit, timespec, exclusive mode ("x") in f[re]open, CMPLX macros.

I'm not even sure which one can be C++-ish bullshit possibly except for about two points:

- Multithreading does seem farfetched for causal users. In fact, I do think it could have been minimized without any actual harm, but multithreading itself needed to be specified because it greatly affects a memory model. (Before C11, C had no thread-aware memory model and different threading implementations were subtly different beyond what the standard stated.) Even JavaScript, originally without no notion of threads, eventually got a thread-aware memory model due to shared web workers. But that never meant JS itself need multithreading support in its standard library, and C could have done the same.

- `_Generic` is even more debatable, though I believe it was the only way forward when we accept <tgmath.h>, which is known to be a response to Fortran (other responses include `restrict`) and was impossible to implement in the portable manner before C11. As long as it retains its scary underline and title case, I guess it's fine.

Most importantly posix already has existing multithreading facilities in posix threads, so it is imperative that they are reformulated in term of the C++11/C11 memory model.

You quoted me before my edit, but fair enough. I do like the "atomics" support.

> "guarantee that `errno` is in TLS"

I suppose that does not mean that I can just avoid setting errno to 0 before calling a function after which I check for errno, right?

Yeah, I do have an issue with stuff like "_Generic" but I assume I can just simply not use it.

What is "quick_exit" exactly and what does it solve?

As for multithreading, I stick to phtread. Is any of the new features a replacement for that or what?

At any rate, why C17 over C11 then?

C17 is a bugfix version of C11 (the next major revision would be C23). The exact list of fixes is available in [1]. Mandating C11 instead of C17 when both are available seems not really useful now.

You have the correct insight about errnos. The new guarantee only means that other threads are not possible to mess with your errnos, but cleaning errnos will be still useful within an individual thread.

exit is not guaranteed to work correctly when called simultaneously from multipe threads, while quick_exit will be okay even in that situation. I think this behavior was not even specified before C11, and only specified after observing existing implementations.

It is expected that libc threading routines are thin wrappers around pthread in Linux. That's why I do think it can be minimized; the only actual problem before C11 was the lack of thread-aware memory model. No need to actually be able to create threads from libc to be honest, especially given that each platform now almost always has a single dominant threading implementation like pthread.

[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2244.htm

My last question would be: is it "OK" to use phtread in my code or are there any alternatives (i.e. "best way") when using C17?

No, just use pthread. There are some useful pthread APIs missing from C17 anyway too.

Thank you for your answers, it is much appreciated.

I suppose I will not use "quick_exit" either in that case, I have many workers, there is a job queue mutex, along with phtread_cond_wait and phtread_mutex_{lock,unlock} and when the "job_quit_flag" is set to true, that means all jobs are done and I am ready to return NULL.

> guarantee that `errno` is in TLS

I mean, that is already true.

There is no such guarantee in C99:

7.5 ¶2: [...] and `errno` which expands to a modifiable lvalue that has type `int`, the value of which is set to a positive error number by several library functions. It is unspecified whether `errno` is a macro or an identifier declared with external linkage. If a macro definition is suppressed in order to access an actual object, or a program defines an identifier with the name `errno`, the behavior is undefined.

7.5 ¶3: The value of `errno` is zero at program startup, but is never set to zero by any library function. The value of `errno` may be set to nonzero by a library function call whether or not there is an error, provided the use of `errno` is not documented in the description of the function in this International Standard.

The fact that `errno` can expand to an lvalue does reflect what is required for multithreading implementations among others, but that's about all.

Nor is it in POSIX, but it's true of all POSIX-like systems that support threading.