Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C array types are weird

anselmschueler.com

Post reply on HN
Print view View original

1–10 of 148 posts

Re: C array types are weird

#2

Post by uecker »

In practice, the [static n] notation can give you useful warnings and bounds checking.

https://godbolt.org/z/PzcjW4zKK

And while the (*array_ptr)[3] notation take a moment to get used to, it is very logical. If you have a pointer to an array, you dereference it first and then indx into it. Again, useful for bounds checking: https://godbolt.org/z/ao1so9KP7

Re: C array types are weird

#5

Post by dnautics »

uecker wrote: post #2

In practice, the [static n] notation can give you useful warnings and bounds checking. https://godbolt.org/z/PzcjW4zKK And while the (*array_ptr)[3] notation take a moment to get used to, it is very logical. If you have a pointer to an array, you dereference it first and then indx into it. Again, useful for bounds checking: https://godbolt.org/z/ao1so9KP7

What is **int[3][5]

Re: C array types are weird

#8

Post by the__alchemist »

This is one of the things that I feel is an inappropriate abstraction that is around for historical reasons. When I do FFI to call C from rust, I usually wrap the generated API (Which is pointer based) into rust's &[] array syntax. Arrays/lists/Vecs etc in most non-C languages feel like an abstraction over a collection of items; I feel like C's exposing the pointer directly is taking a low-level memory/MMIO operation and inserting it into business logic. Conceptually, I like to keep them separate; pointers for writing drivers, accessing registers, writing to flash memory etc. Arrays/lists/vecs for higher level operations on collections.

Tangent: I have a pet theory that part of Zig's raison d'etre is to fix some of the problems with C, while accommodating its pointer-based data structures, and the resulting patterns.

Re: C array types are weird

#9

Post by vulcan01 »

the__alchemist wrote: post #8

This is one of the things that I feel is an inappropriate abstraction that is around for historical reasons. When I do FFI to call C from rust, I usually wrap the generated API (Which is pointer based) into rust's &[] array syntax. Arrays/lists/Vecs etc in most non-C languages feel like an abstraction over a collection of items; I feel like C's exposing the pointer directly is taking a low-level memory/MMIO operation…

This talk – "Programming without pointers" – by Andrew Kelley may be interesting to you.

https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e83...

Re: C array types are weird

#10

Post by ori_b »

dnautics wrote: post #5
uecker wrote: post #2

In practice, the [static n] notation can give you useful warnings and bounds checking. https://godbolt.org/z/PzcjW4zKK And while the (*array_ptr)[3] notation take a moment to get used to, it is very logical. If you have a pointer to an array, you dereference it first and then indx into it. Again, useful for bounds checking: https://godbolt.org/z/ao1so9KP7

What is **int[3][5]

A syntax error. You need a variable name, not a type name, in the middle.
Post reply on HN