I think the documentation is outdated given that C11 atomics [1] and threads [2] are available for more than a year now. Same goes for pretty much everything MSVC frontend related stuff (I've yet to try which C++23 features are supported at the moment, but they've secretly added support for C23 features like typeof and attributes, as well as GNU Statement Expressions).

[1]: https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual...

[2]: https://devblogs.microsoft.com/cppblog/c11-threads-in-visual...

Outdated documentation is pretty normal unfortunely, even .NET suffers from that nowadays.

Not as bad as Apple nowadays though, quite far from Inside Inside Macintosh days.

Glad to know about C23 features, as they went silent on C23 plans.

C++23 looks quite bad for anything that requires frontend changes, there are even developer connection issues for us to tell what to prioritise, as if it wasn't logically all of it. There is another one for C++26 as well.

Personally, I think that with the improvements on low level coding and AOT compilation from managed languages, we are reaching local optimum, where C and C++ are good enough for the low level glue, C23 and C++23 (eventually C++26 due to static reflection) might be the last ones that are actually relevant.

Similar to how although COBOL and Fortran standards keep being updated, how many ISO 2023 revision compliant compilers are you going to find out for portable code?

> Outdated documentation is pretty normal unfortunely, even .NET suffers from that nowadays.

That's really unfortunate.

> Not as bad as Apple nowadays though, quite far from Inside Inside Macintosh days.

Funny story, I know a guy who wanted to write a personal Swift project for an esoteric spreadsheet format and the quality of the documentation of SwiftUI made him ragequit. After that, he switched to kotlin native and gtk and he is much happier.

> Personally, I think that with the improvements on low level coding and AOT compilation from managed languages, we are reaching local optimum, where C and C++ are good enough for the low level glue, C23 and C++23 (eventually C++26 due to static reflection) might be the last ones that are actually relevant.

I agree on the managed language thing but, I mean, the fact that other languages are getting more capable with low level resources does not mean that improvements in C/C++ are a bad idea and will not be used. In fact, I think that features like the transcoding functions in <stdmchar.h> in C2y (ironically those are relevant to the current HN post) are useful to those languages too! So even if C, C++ and fortran are just used for numerical kernels, emulators, hardware stuff, glue code and other "dirty" code advancements made to them are not going wasted.

Are C multidimensional arrays guaranteed to be contiguous in memory? In practice they are, but can one iterate through them just by incrementing a pointer which points to the first element without UB?

Yes. All arrays in C are contiguous. Multidimensional arrays are just arrays of arrays, and are therefore also contiguous.

Source: https://stackoverflow.com/questions/36647286/are-c-multidime...

Yes, but is one allowed to move a pointer inside it as they see fit? On a one-dimensional array, one can iterate through it starting with a pointer pointing to the first element and ending with a pointer pointing one position past the last element (which the user is not allowed to dereference). For multidimensional arrays, the element type is an array too (with a smaller rank than the original one), so one could perform that type of iteration with a pointer to an array. My question is whether a pointer to the underlying scalar type can freely move inside the multidimensional array without UB, since it may have to actually leave the array it was originally part of. If that's not allowed, how could one build slices and other view types?

Yes, you can do that, it's fine as long as you stay within the bounds of the indexes. Under the hood, it's a single contiguous block of memory.

Although at least with 2d arrays I prefer to just use a 1d array and index it with [x * width + y], because one problem with multidimensional arrays in C is they need multiple allocations/frees.

Why would you need multiple allocations?

edit: Isn't it just:

  float (*arr)[m][n] = malloc(sizeof(*arr));

You have to allocate the size for m and n, because C arrays decay bare pointers.

But it seems to work, which I didn't expect[0]. It also seems like you have to de-reference it to use it which is weird.

[0]https://onlinegdb.com/HwX-WTL5t

Double indirection arrays with multiple allocations are 25 years obsolete (ok, there are some use cases) but since C99 we prefer to do it like the parent.

In your code link you over allocate memory, sizeof *arr is enough and you need to dereference like with (*arr)[i][j]. You need to dereference it because it is a pointer to an array, if you dereference you get an array. You can also let the first dimensions decay then it looks like:

  double (*arr)[m] = malloc(n * sizeof *arr);
  arr[i][j] = ...

but this is not as safe because the bound of the outermost dimension is lost. (Edited)

Do you happen to have any source/book on why you can't use anything but a conservative gc on C-like languages? I would really like to know why that's the case.

Basically C semantics are to blame, due to the way C was designed, and the liberties it allows its users, it is like programming in Assembly from a tracing GC point of view.

Meaning that without any kind of metadata, the GC has to assume that any kind of value on the stack or global memory segments is a possible pointer, but it cannot be sure about it, it might be just a numeric value that looks like a valid pointer to GC allocated data.

So any algorithm that needs to be certain about the exact data types, before moving the wrong data, is already off the table in regards to C.

See https://hboehm.info/gc/ for more info, including the references.

Thank you!

There is a compatibilty chart: https://www.graalvm.org/python/compatibility/

There is always qbe if you need something simpler

> At least it does generics now

Not in gccgo

Indeed, as you see on other remarks from me I am aware of it, my point was about the language as designed, not the implementations ecosystem.

TinyGo also doesn't do them.

Maybe cranelift will help with this. Faster compile times is one of its selling points.

That is something that I also look forward to.

> using LLVM backends

Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

TinyGo.

- Though freeware and not foss, there is also pellesc over at Windows land, with almost full C23 support.

- For small 8 bit systems, SDCC is an excellent choice, supporting even C23 features! Also its lead maintainer is a committee member with really useful contributions to the standard.

- I have heard the RiscOS compiler is pretty cool and supports modern standards. That one uses the Norcroft frontend.

I agree with you in that we need a production level C compiler written in C. Though that is not a simple task and the C community nowadays prefers to engage on infighting over pedantic issues or rust rather than working together. A simple example of this is the lack of a modern library ecosystem, while everyone and their mother has their own custom build system. Even though C is sold as a performant language, there isn't a single parallelism library like OneTBB, Kokkos or HPX over at C++. Don't get me started on vendors not offering good standard support (Microsoft, macos-libc, OpenBSD libc)...

One correction though, cparser uses libfirm as a backend, not qbe. Also the author of chibicc has stopped writing that book AFAIK.

Bonus non-c based entries: - The zig community is working on arocc. Judging by the awesomeness of zig cc, these are really good news. - Nvidia offers their EDG based nvc with OpenACC support for free these days, which is cool.

Edit: formatting

A possible answer is that one could modify n inside the function body, which means that the length is lost. But honestly, one could just use const to avoid this. Though, pointers to VLAs are really useful and convenient when allocating dynamic arrays, especially multidimensional.

GCC only works in the first case anyway: https://godbolt.org/z/jo57r1MW4 One could add in the other too, but language semantics currently do not allow this.

Changing the n later has no impact on the size of the arrays later and the compiler is perfectly able to remember the original size.