{"article":{"slug":"c-for-rust-programmers","title":"C for Rust Programmers","subtitle":null,"summary":"A guide to the C programming language written from the perspective of someone who learned Rust first. BD103 walks through the surprising and unexpected parts of C for Rust programmers, including booleans and headers, strings and pointer lengths, integer types like size_t, the arrow operator, and the memory safety pitfalls Rust usually prevents.","content_type":"tutorial","language":"en","canonical_url":"https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/","author":{"name":"BD103","url":"https://bd103.dev/","person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"BD103's Blog","url":"https://bd103.dev/","listing_slug":null,"listing":null},"topics":[{"name":"Rust","slug":"rust","url":"https://listedarticles.com/topics/rust"},{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Systems Programming","slug":"systems-programming","url":"https://listedarticles.com/topics/systems-programming"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":2046,"reading_minutes":9,"published_at":"2026-10-07T00:00:00.000Z","added_at":"2026-10-07T17:13:33.946Z","updated_at":"2026-10-07T17:13:33.946Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/c-for-rust-programmers","markdown_url":"https://listedarticles.com/articles/c-for-rust-programmers.md","example":false,"citation":"BD103, BD103's Blog. \"C for Rust Programmers.\" 7 Oct 2026. https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/ (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/"},"body_markdown":"# C for Rust Programmers\n\nThe very first systems programming language I ever learned was Rust. This is uncommon compared to many other programmers; you're more likely to find someone who learned C or C++ first before coming to Rust. As such, there are plenty of \"Rust for C Programmers\" articles on the internet, but little to no \"C for Rust Programmers\" articles out there.\n\nWell, I'm about to change that! I've been learning C and C++ recently, and *holy cow those languages are quirky*. This blog post is a collection of eyebrow-raising details I learned while teaching myself C. (No C++ today, I'm not ready to dig into that can of worms.) This is not a substitute for a proper C tutorial, you'll need to Google one of those yourself. Rather, it's a list of things to keep in mind when working in the language.\n\nWith the premise set, let's draw the curtain and see what C has to offer!\n\n## Boolean Is Not* Built-In\n\nThe original version of C did not have a primitive type for booleans, programs instead used the integers 0 and 1. This was changed in [C99](https://en.wikipedia.org/wiki/C99), which added booleans in the optional [``](https://en.cppreference.com/c/header/stdbool) header[\\[1\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-_bool):\n\n```\n#include \nint main() {\n bool yes = true;\n bool no = false;\n return 0;\n}\n```\nEven still, `true` and `false` are not literals or keywords like in other languages. Instead, they are definitions that expand to 1 and 0:\n\n```\n#define true 1\n#define false 0\n```\nThis was changed again in [C23]()[\\[2\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-c23), so now booleans are true language primitives, but if you're compiling for earlier versions you'll need to include ``.\n\n## Null-Terminated Strings\n\nA Rust [`&str`](https://doc.rust-lang.org/stable/std/primitive.str.html) is 16 bytes: 8 bytes for the memory address and 8 bytes for the string length. This is because `str` is a dynamically sized type, and uses [pointer metadata](https://bd103.dev/blog/2023-08-06-ptr-metadata/) to track the length of the string.\n\n```\n// While a normal reference uses only 8 bytes...\nassert_eq!(std::mem::size_of::<&u8>(), 8);\n// ...strings use 16 bytes.\nassert_eq!(std::mem::size_of::<&str>(), 16);\n```\nThis approach makes fetching the string length extremely efficient, but requires more memory per `&str` reference. C uses a different approach: it doesn't store the size of its strings separately, but instead terminates every single string with a null byte (`\\0`). This is an intentional trade off that results in a few things:\n\n- C programs don't need to keep track of an extra `size` variable alongside the string[\\[3\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-extra-size-variable)\n- Every single string needs room at the end for a null byte\n - This means empty strings `\"\"` still take up one byte of memory!\n- This means empty strings \n- Null bytes cannot easily be used in the middle of a string without messing up [``](https://cppreference.com/c/header/string) 's functions\n- Forgetting the null terminator can result in out-of-bound reads\n\nIn practice, this requires you to remember to allocate extra space for the null terminator and insert it at the end of strings. For example, here is a program that reverses a string in C:\n\n```\nchar* reverse(char* forward) {\n // Calculate the string's length, excluding the null terminator.\n unsigned long len = strlen(forward);\n // Allocate enough room for the string and its null terminator.\n char* reversed = malloc(len + 1);\n for (int i = 0; i < len; i++) {\n reversed[i] = forward[len - 1 - i];\n }\n // Add the null terminator at the end.\n reversed[len] = '\\0';\n return reversed;\n}\n```\nNote lines 5 and 12, which take special measure to account for the null terminator. For reference, the corresponding Rust function[\\[4\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-rust-reverse-string) doesn't need to do so:\n\n```\nfn reverse(forward: &[u8]) -> Box<[u8]> {\n let len = forward.len();\n let mut reversed = Box::<[u8]>::new_uninit_slice(len);\n for i in 0..len {\n reversed[i].write(forward[len - 1 - i]);\n }\n unsafe { reversed.assume_init() }\n}\n```\n## Target-Dependent Integer Widths\n\nC's integer types are not guaranteed to use an exact number of bits, instead the width varies depending on the target platform.\n\n| Type | C Standard | 64-bit Unix | 64-bit Windows | \n|---|---|---|---|\n| `char` | at least 8 bits | 8 bits | 8 bits | \n| `short` | at least 16 bits | 16 bits | 16 bits | \n| `int` | at least 16 bits | 32 bits | 32 bits | \n| `long` | at least 32 bits | 64 bits | 32 bits | \n| `long long` | at least 64 bits | 64 bits | 64 bits | \n\n[via cppreference.com](https://cppreference.com/c/language/arithmetic_types)\n\n`long` being 64 bits on Unix and 32 bits on Windows particularly irks me. I recommend following the advice that [a friend of mine](https://github.com/magicalbat) gave me a few years ago: if you care about cross-platform compatibility, only use the fixed width integers provided by [``](https://cppreference.com/c/header/stdint):\n\n| Rust | C | \n|---|---|\n| `u8` | `uint8_t` | \n| `u16` | `uint16_t` | \n| `u32` | `uint32_t` | \n| `u64` | `uint64_t` | \n| `usize` | `size_t`[\\[5\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-size_t-and-ptrdiff_t) | \n| `i8` | `int8_t` | \n| `i16` | `int16_t` | \n| `i32` | `int32_t` | \n| `i64` | `int64_t` | \n| `isize` | `ptrdiff_t`[\\[5\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-size_t-and-ptrdiff_t) | \n\n## Error Handling Sucks\n\nI really love Rust's error handling. [`Result`](https://doc.rust-lang.org/stable/std/result/enum.Result.html) forces you to address errors, and sum types (`enum`s) and `match` statements make doing so really easy!\n\nC's error handling story, in comparison, is straight up tragic. It seems to boil down to functions returning a \"magic integer\" like -1 or a null pointer to signal there was an error. You can get a little bit more information by reading [`errno`](https://cppreference.com/c/error/errno), a thread-local integer that can be used to check for specific kinds of errors, but in terms of getting actual error messages and stack traces it is much harder.\n\nWhen writing C, one of the biggest things you'll notice is that the language will never force you to handle errors. It's up to you to remember that functions can fail. For example, here's a snippet of code from [Null-Terminated Strings](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#null-terminated-strings):\n\n```\n// Allocate enough room for the string and its null terminator.\nchar* reversed = malloc(len + 1);\nfor (int i = 0; i < len; i++) {\n reversed[i] = forward[len - 1 - i];\n}\n```\nTo new programmers, it's not immediately obvious that [`malloc()`](https://cppreference.com/c/memory/malloc) can fail and return a null pointer. If your machine runs out of memory, `reversed[i]` will cause a segfault upon being accessed. In order to avoid unhelpful segfaults, the program should check for a null pointer and gracefully exit if one is found:\n\n```\nchar* reversed = malloc(len + 1);\nif (reversed == NULL) {\n perror(\"Error\");\n exit(1);\n}\n```\nDoing so provides a much better experience than a segfault, or worse, other unintentional behavior:\n\n```\n$ ./main\nError: Cannot allocate memory\n```\nOf course, remembering to check every single allocated pointer isn't an amazing developer experience. An approach I played around with was recreating Rust's `Result` in C using tagged unions:\n\n```\nstruct MallocResult {\n enum Tag { OK, ERROR } tag;\n union Value {\n void* ptr;\n char* error_message;\n } value;\n};\n```\nIt's a complete mess to use, however, and there's *still* nothing stopping you from immediately accessing `result.value.ptr` without handling the error first. The lack of visibility modifiers like `private` and `public`, which could be used to prevent this, appear to be an intentional design decision. C places full trust in the programmer to *do things right™* and gives few facilities for contracts or safe abstractions.\n\nI personally disagree with this approach. I'm not some mastermind programming wizard who never makes mistakes. I'd much rather encode program requirements into the type system so that the compiler can check them for me![\\[6\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-fearless-simd) That way, I can be reasonably certain that if the code compiles it was written correctly. But I digress.\n\n## Field Access Syntax\n\nC has two different field access operators: [`.`](https://cppreference.com/c/language/operator_member_access#Member_access) for values and [`->`](https://cppreference.com/c/language/operator_member_access#Member_access_through_pointer) for pointers.\n\n```\nstruct Foo {\n int field;\n};\nstruct Foo value = { 103 };\nstruct Foo* ptr = &value;\n// Accessing the field directly.\nprintf(\"%d\\n\", value.field);\n// Accessing the field through a pointer.\nprintf(\"%d\\n\", ptr->field);\n```\nThis caught me off guard at first, as Rust uses `.` for everything.\n\nIf your curious, [this Stack Overflow write up](https://stackoverflow.com/a/13366168) provides some interesting history on why the `->` operator exists.[\\[7\\]](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fn-cursed-arrow-operator)\n\n## Arrays Become Pointers for Fun\n\nArrays have some weird nuance to them. Sometimes they are plain values with their length accessible using [`sizeof()`](https://cppreference.com/c/language/sizeof), other times they are pointers with an unknown size. In general, this is determined by whether you are handling the array within the function it was defined or not.\n\nTo showcase what I mean, here's a very simple C program that prints the size of two arrays:\n\n```\nchar declared_size[3] = { 1, 2, 3 };\nchar inferred_size[] = { 4, 5, 6 };\nprintf(\"Declared size (main): %ld bytes\\n\", sizeof(declared_size));\nprintf(\"Inferred size (main): %ld bytes\\n\", sizeof(inferred_size));\n```\nWhen run, this programs tells you that both arrays take 3 bytes of memory. Good!\n\n```\n$ ./main\nDeclared size (main): 3 bytes\nInferred size (main): 3 bytes\n```\nNow, let's make a slight modification. Let's pass `declared_size` and `inferred_size` through a function before printing its size:\n\n```\nvoid function(char declared_size[3], char inferred_size[]) {\n printf(\"Declared size (function): %ld bytes\\n\", sizeof(declared_size));\n printf(\"Inferred size (function): %ld bytes\\n\", sizeof(inferred_size));\n}\n```\nNone of the logic changed, the arrays are identical to the previous example, however now the program reports each array takes **8 bytes of memory**:\n\n```\n$ ./main\nDeclared size (function): 8 bytes\nInferred size (function): 8 bytes\n```\nWhy? Because any array passed through a function is *implicitly converted* to a pointer to the first element. From the C compiler's perspective, the above function actually had the following type signature:\n\n`void function(char* declared_size, char* inferred_size);`\nThis is why it confusingly looked like each array was 8 bytes long. The arrays themselves are 3 bytes, but the pointers take up 8 bytes of memory! Handily, Clang raises a warning when you run `sizeof()` on the pointer form of an array, making it easier to catch this mistake:\n\n```\n$ clang main.c\n06-arrays/main.c:5:59: warning: sizeof on array function parameter will return size of 'char *'\n instead of 'char[3]' [-Wsizeof-array-argument]\n 5 | printf(\"Declared size (function): %ld bytes\\n\", sizeof(declared_size));\n | ^\n06-arrays/main.c:4:20: note: declared here\n 4 | void function(char declared_size[3], char inferred_size[]) {\n | ^\n06-arrays/main.c:6:59: warning: sizeof on array function parameter will return size of 'char *'\n instead of 'char[]' [-Wsizeof-array-argument]\n 6 | printf(\"Inferred size (function): %ld bytes\\n\", sizeof(inferred_size));\n | ^\n06-arrays/main.c:4:43: note: declared here\n 4 | void function(char declared_size[3], char inferred_size[]) {\n | ^\n2 warnings generated.\n```\n## Oh Yeah References Don't Exist\n\nI'd be remiss if I didn't mention it once. C has no borrow checking, and no concept of references. It's all [raw pointers](https://doc.rust-lang.org/stable/std/primitive.pointer.html). This means you can do fun pointer arithmetic like so:\n\n```\nint array[] = { 0, 1, 2, 3, 4, 5 };\n// Woah, iterating over pointers instead of indexes!\nfor (int* x = &array[0]; x < &array[6]; x++) {\n *x = 5 - *x;\n}\n```\nHowever, I'm not sure how good an idea that is. 😅\n\nEither way, be careful when you mess with pointers. Making mistakes with memory results in buffer overflows and out-of-bounds writes, which provide significant threats to the security of your code.\n\n## Conclusion\n\nI hope you enjoyed this article! I've honestly had a lot of fun learning C. And while I doubt I'll reach for it for personal projects, it's absolutely a crucial language to know as a systems programmer. All the examples in this blog are [available on Github](https://github.com/BD103/C-for-Rust-Programmers), if you'd like to mess with them yourself!\n\nUntil next time,\n\n- BD103 :)\n\n1. \nTechnically you can use [`_Bool`](https://en.cppreference.com/c/keyword/_Bool) without the header, but you still need it for the`true` and`false` definitions.[↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-_bool-1)\n2. \nIt looks like [Clang still has only partial support for C23](https://clang.llvm.org/c_status.html) , so you may need to wait a little while longer before chucking away your`#include ` statements.[↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-c23-1)\n3. \nAs described previously, this is essentially what Rust does. In C this would be an ergonomic pain, but Rust's language features make it so a programmer never needs to consider the pointer and the string length as separate variables. [↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-extra-size-variable-1)\n4. \nThe corresponding Rust function is not idiomatic, and can only correctly handle ASCII text. If I were writing a production version of this function, it would be a single line of code: `forward.chars().rev().collect::()` .[↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-rust-reverse-string-1)\n5. \n[`usize`](https://doc.rust-lang.org/stable/std/primitive.usize.html) and[`isize`](https://doc.rust-lang.org/stable/std/primitive.isize.html) don't perfectly map semantically to[`size_t`](https://cppreference.com/c/types/size_t) and[`ptrdiff_t`](https://cppreference.com/c/types/ptrdiff_t) . I don't fully understand the difference, however, so I recommend doing your own research before using these types.[↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-size_t-and-ptrdiff_t-1)[↩2](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-size_t-and-ptrdiff_t-2)\n6. \n[This blog post on Fearless SIMD](https://shnatsel.github.io/safe-simd-in-rust-even-on-the-inside/) provides a great example of using Rust's type system to guarantee the correctness of code. I highly recommend giving it a read![↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-fearless-simd-1)\n7. \nMy favorite line of code from that post is `100->a = 0;` , it's so cursed![↩](https://bd103.dev/blog/2026-10-07-c-for-rust-programmers/#fr-cursed-arrow-operator-1)","body_html":"

C for Rust Programmers

\n

The very first systems programming language I ever learned was Rust. This is uncommon compared to many other programmers; you're more likely to find someone who learned C or C++ first before coming to Rust. As such, there are plenty of "Rust for C Programmers" articles on the internet, but little to no "C for Rust Programmers" articles out there.

\n

Well, I'm about to change that! I've been learning C and C++ recently, and holy cow those languages are quirky. This blog post is a collection of eyebrow-raising details I learned while teaching myself C. (No C++ today, I'm not ready to dig into that can of worms.) This is not a substitute for a proper C tutorial, you'll need to Google one of those yourself. Rather, it's a list of things to keep in mind when working in the language.

\n

With the premise set, let's draw the curtain and see what C has to offer!

\n

Boolean Is Not* Built-In

\n

The original version of C did not have a primitive type for booleans, programs instead used the integers 0 and 1. This was changed in C99, which added booleans in the optional <stdbool.h> header<sup>[1]</sup>:

\n
#include <stdbool.h>\nint main() {\n    bool yes = true;\n    bool no = false;\n    return 0;\n}
\n

Even still, true and false are not literals or keywords like in other languages. Instead, they are definitions that expand to 1 and 0:

\n
#define true 1\n#define false 0
\n

This was changed again in C23<sup>[2]</sup>, so now booleans are true language primitives, but if you're compiling for earlier versions you'll need to include <stdbool.h>.

\n

Null-Terminated Strings

\n

A Rust &str is 16 bytes: 8 bytes for the memory address and 8 bytes for the string length. This is because str is a dynamically sized type, and uses pointer metadata to track the length of the string.

\n
// While a normal reference uses only 8 bytes...\nassert_eq!(std::mem::size_of::<&u8>(), 8);\n// ...strings use 16 bytes.\nassert_eq!(std::mem::size_of::<&str>(), 16);
\n

This approach makes fetching the string length extremely efficient, but requires more memory per &str reference. C uses a different approach: it doesn't store the size of its strings separately, but instead terminates every single string with a null byte (\\0). This is an intentional trade off that results in a few things:

\n
  • C programs don't need to keep track of an extra size variable alongside the string<sup>[3]</sup>
  • Every single string needs room at the end for a null byte
    • This means empty strings "" still take up one byte of memory!
  • This means empty strings
  • Null bytes cannot easily be used in the middle of a string without messing up <string.h> 's functions
  • Forgetting the null terminator can result in out-of-bound reads
\n

In practice, this requires you to remember to allocate extra space for the null terminator and insert it at the end of strings. For example, here is a program that reverses a string in C:

\n
char* reverse(char* forward) {\n    // Calculate the string's length, excluding the null terminator.\n    unsigned long len = strlen(forward);\n    // Allocate enough room for the string and its null terminator.\n    char* reversed = malloc(len + 1);\n    for (int i = 0; i < len; i++) {\n        reversed[i] = forward[len - 1 - i];\n    }\n    // Add the null terminator at the end.\n    reversed[len] = '\\0';\n    return reversed;\n}
\n

Note lines 5 and 12, which take special measure to account for the null terminator. For reference, the corresponding Rust function<sup>[4]</sup> doesn't need to do so:

\n
fn reverse(forward: &[u8]) -> Box<[u8]> {\n    let len = forward.len();\n    let mut reversed = Box::<[u8]>::new_uninit_slice(len);\n    for i in 0..len {\n        reversed[i].write(forward[len - 1 - i]);\n    }\n    unsafe { reversed.assume_init() }\n}
\n

Target-Dependent Integer Widths

\n

C's integer types are not guaranteed to use an exact number of bits, instead the width varies depending on the target platform.

\n
TypeC Standard64-bit Unix64-bit Windows
charat least 8 bits8 bits8 bits
shortat least 16 bits16 bits16 bits
intat least 16 bits32 bits32 bits
longat least 32 bits64 bits32 bits
long longat least 64 bits64 bits64 bits
\n

via cppreference.com

\n

long being 64 bits on Unix and 32 bits on Windows particularly irks me. I recommend following the advice that a friend of mine gave me a few years ago: if you care about cross-platform compatibility, only use the fixed width integers provided by <stdint.h>:

\n
RustC
u8uint8_t
u16uint16_t
u32uint32_t
u64uint64_t
usizesize_t<sup>[5]</sup>
i8int8_t
i16int16_t
i32int32_t
i64int64_t
isizeptrdiff_t<sup>[5]</sup>
\n

Error Handling Sucks

\n

I really love Rust's error handling. Result forces you to address errors, and sum types (enums) and match statements make doing so really easy!

\n

C's error handling story, in comparison, is straight up tragic. It seems to boil down to functions returning a "magic integer" like -1 or a null pointer to signal there was an error. You can get a little bit more information by reading errno, a thread-local integer that can be used to check for specific kinds of errors, but in terms of getting actual error messages and stack traces it is much harder.

\n

When writing C, one of the biggest things you'll notice is that the language will never force you to handle errors. It's up to you to remember that functions can fail. For example, here's a snippet of code from Null-Terminated Strings:

\n
// Allocate enough room for the string and its null terminator.\nchar* reversed = malloc(len + 1);\nfor (int i = 0; i < len; i++) {\n    reversed[i] = forward[len - 1 - i];\n}
\n

To new programmers, it's not immediately obvious that malloc() can fail and return a null pointer. If your machine runs out of memory, reversed[i] will cause a segfault upon being accessed. In order to avoid unhelpful segfaults, the program should check for a null pointer and gracefully exit if one is found:

\n
char* reversed = malloc(len + 1);\nif (reversed == NULL) {\n    perror("Error");\n    exit(1);\n}
\n

Doing so provides a much better experience than a segfault, or worse, other unintentional behavior:

\n
$ ./main\nError: Cannot allocate memory
\n

Of course, remembering to check every single allocated pointer isn't an amazing developer experience. An approach I played around with was recreating Rust's Result in C using tagged unions:

\n
struct MallocResult {\n    enum Tag { OK, ERROR } tag;\n    union Value {\n        void* ptr;\n        char* error_message;\n    } value;\n};
\n

It's a complete mess to use, however, and there's still nothing stopping you from immediately accessing result.value.ptr without handling the error first. The lack of visibility modifiers like private and public, which could be used to prevent this, appear to be an intentional design decision. C places full trust in the programmer to do things right™ and gives few facilities for contracts or safe abstractions.

\n

I personally disagree with this approach. I'm not some mastermind programming wizard who never makes mistakes. I'd much rather encode program requirements into the type system so that the compiler can check them for me!<sup>[6]</sup> That way, I can be reasonably certain that if the code compiles it was written correctly. But I digress.

\n

Field Access Syntax

\n

C has two different field access operators: . for values and -> for pointers.

\n
struct Foo {\n    int field;\n};\nstruct Foo value = { 103 };\nstruct Foo* ptr = &value;\n// Accessing the field directly.\nprintf("%d\\n", value.field);\n// Accessing the field through a pointer.\nprintf("%d\\n", ptr->field);
\n

This caught me off guard at first, as Rust uses . for everything.

\n

If your curious, this Stack Overflow write up provides some interesting history on why the -> operator exists.[7]

\n

Arrays Become Pointers for Fun

\n

Arrays have some weird nuance to them. Sometimes they are plain values with their length accessible using sizeof(), other times they are pointers with an unknown size. In general, this is determined by whether you are handling the array within the function it was defined or not.

\n

To showcase what I mean, here's a very simple C program that prints the size of two arrays:

\n
char declared_size[3] = { 1, 2, 3 };\nchar inferred_size[] = { 4, 5, 6 };\nprintf("Declared size (main): %ld bytes\\n", sizeof(declared_size));\nprintf("Inferred size (main): %ld bytes\\n", sizeof(inferred_size));
\n

When run, this programs tells you that both arrays take 3 bytes of memory. Good!

\n
$ ./main\nDeclared size (main): 3 bytes\nInferred size (main): 3 bytes
\n

Now, let's make a slight modification. Let's pass declared_size and inferred_size through a function before printing its size:

\n
void function(char declared_size[3], char inferred_size[]) {\n    printf("Declared size (function): %ld bytes\\n", sizeof(declared_size));\n    printf("Inferred size (function): %ld bytes\\n", sizeof(inferred_size));\n}
\n

None of the logic changed, the arrays are identical to the previous example, however now the program reports each array takes 8 bytes of memory:

\n
$ ./main\nDeclared size (function): 8 bytes\nInferred size (function): 8 bytes
\n

Why? Because any array passed through a function is implicitly converted to a pointer to the first element. From the C compiler's perspective, the above function actually had the following type signature:

\n

void function(char* declared_size, char* inferred_size);\nThis is why it confusingly looked like each array was 8 bytes long. The arrays themselves are 3 bytes, but the pointers take up 8 bytes of memory! Handily, Clang raises a warning when you run sizeof() on the pointer form of an array, making it easier to catch this mistake:

\n
$ clang main.c\n06-arrays/main.c:5:59: warning: sizeof on array function parameter will return size of 'char *'\n      instead of 'char[3]' [-Wsizeof-array-argument]\n    5 |     printf("Declared size (function): %ld bytes\\n", sizeof(declared_size));\n      |                                                           ^\n06-arrays/main.c:4:20: note: declared here\n    4 | void function(char declared_size[3], char inferred_size[]) {\n      |                    ^\n06-arrays/main.c:6:59: warning: sizeof on array function parameter will return size of 'char *'\n      instead of 'char[]' [-Wsizeof-array-argument]\n    6 |     printf("Inferred size (function): %ld bytes\\n", sizeof(inferred_size));\n      |                                                           ^\n06-arrays/main.c:4:43: note: declared here\n    4 | void function(char declared_size[3], char inferred_size[]) {\n      |                                           ^\n2 warnings generated.
\n

Oh Yeah References Don't Exist

\n

I'd be remiss if I didn't mention it once. C has no borrow checking, and no concept of references. It's all raw pointers. This means you can do fun pointer arithmetic like so:

\n
int array[] = { 0, 1, 2, 3, 4, 5 };\n// Woah, iterating over pointers instead of indexes!\nfor (int* x = &array[0]; x < &array[6]; x++) {\n    *x = 5 - *x;\n}
\n

However, I'm not sure how good an idea that is. 😅

\n

Either way, be careful when you mess with pointers. Making mistakes with memory results in buffer overflows and out-of-bounds writes, which provide significant threats to the security of your code.

\n

Conclusion

\n

I hope you enjoyed this article! I've honestly had a lot of fun learning C. And while I doubt I'll reach for it for personal projects, it's absolutely a crucial language to know as a systems programmer. All the examples in this blog are available on Github, if you'd like to mess with them yourself!

\n

Until next time,

\n
  • BD103 :)
\n
\n

Technically you can use _Bool without the header, but you still need it for thetrue andfalse definitions.↩

\n
\n

It looks like Clang still has only partial support for C23 , so you may need to wait a little while longer before chucking away your#include <stdbool.h> statements.↩

\n
\n

As described previously, this is essentially what Rust does. In C this would be an ergonomic pain, but Rust's language features make it so a programmer never needs to consider the pointer and the string length as separate variables. ↩

\n
\n

The corresponding Rust function is not idiomatic, and can only correctly handle ASCII text. If I were writing a production version of this function, it would be a single line of code: forward.chars().rev().collect::<String>() .↩

\n
\n

usize andisize don't perfectly map semantically tosize_t andptrdiff_t . I don't fully understand the difference, however, so I recommend doing your own research before using these types.↩↩2

\n
\n

This blog post on Fearless SIMD provides a great example of using Rust's type system to guarantee the correctness of code. I highly recommend giving it a read\"↩\"

\n
\n

My favorite line of code from that post is 100->a = 0; , it's so cursed\"↩\"

","headings":[{"level":1,"text":"C for Rust Programmers","id":"c-for-rust-programmers"},{"level":2,"text":"Boolean Is Not* Built-In","id":"boolean-is-not-built-in"},{"level":2,"text":"Null-Terminated Strings","id":"null-terminated-strings"},{"level":2,"text":"Target-Dependent Integer Widths","id":"target-dependent-integer-widths"},{"level":2,"text":"Error Handling Sucks","id":"error-handling-sucks"},{"level":2,"text":"Field Access Syntax","id":"field-access-syntax"},{"level":2,"text":"Arrays Become Pointers for Fun","id":"arrays-become-pointers-for-fun"},{"level":2,"text":"Oh Yeah References Don't Exist","id":"oh-yeah-references-don-t-exist"},{"level":2,"text":"Conclusion","id":"conclusion"}]}}