So You Think You Can Const?

So You Think You Can `const`

Think you you know all the const rules for C? Think again.

Previously: How to C

Basic `const`

Scalar

You’re familiar with simple const rule in C.

const uint32_t hello = 3;

const on hello means at compile time your compiler verifies hello never changes.

If you try to modify or re-assign hello, your compiler stops you:


clang-700.1.81:
error: read-only variable is not assignable
    hello++;
    ~~~~~^
error: read-only variable is not assignable
    hello = 92;
    ~~~~~ ^


gcc-5.3.0:
error: increment of read-only variable 'hello'
     hello++;
          ^
error: assignment of read-only variable 'hello'
     hello = 92;
           ^

Additionally, C doesn’t really care where const shows up as long as it’s before your identifier, so const uint32_t and uint32_t const are identical:

const uint32_t hello = 3;
uint32_t const hello = 3;

Prototypal Scalar Const

Compare the following function prototype versus implementation:

void printTwo(uint32_t a, uint64_t b);

void printTwo(const uint32_t a, const uint64_t b) {
    printf("%" PRIu32 " %" PRIu64 "\n", a, b);
}

Will your compiler complain if printTwo() implementation has scalar const parameters but its prototype doesn’t?

Nope.

It’s perfectly okay to have mismatching prototype const qualifiers for scalar implementation arguments.

Why is this okay? Pretty simple: there’s no way your function can modify a or b outside of the function scope itself, so const has no impact on any callers of your function. Your compiler is smart enough to know it will be copying the scalars a and b, so const-vs-not-const has no impact on the physical or mental models of your program here.

Your compiler won’t care if you have mismatching const for any non-pointer or non-array parameters since those will be copied directly by value and the original values at the caller will always remain unmodified¹.

Though, your compiler will complain if you have mismatching const with pointer or array parameter data because then your function has the ability to manipulate pointed-to data passed in which must be agreed upon by the caller as well as the callee.

Array

You can const an entire array declaration.

const uint16_t things[] = {5, 6, 7, 8, 9};

const can still be after the type as well:

uint16_t const things[] = {5, 6, 7, 8, 9};

If you try to modify things[], your compiler stops you:


clang-700.1.81:
error: read-only variable is not assignable
    things[3] = 12;
    ~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location 'things[3]'
     things[3] = 12;
               ^

Struct

Regular Struct

You can const an entire struct.

struct aStruct {
    int32_t a;
    uint64_t b;
};

const struct aStruct someStructA = {.a = 3, .b = 4};

Or:

struct const aStruct someStructA = {.a = 3, .b = 4};

If we try to modify any members of someStructA:

someStructA.a = 9;

We get an error because someStructA is declared as const. We can’t modify members after declaration.


clang-700.1.81:
error: read-only variable is not assignable
    someStructA.a = 9;
    ~~~~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of member 'a' in read-only object
     someStructA.a = 9;
                   ^

Internal `const` Struct

You can const individual members of a struct.

struct anotherStruct {
    int32_t a;
    const uint64_t b;
}; 

struct anotherStruct someOtherStructB = {.a = 3, .b = 4};

If we try to modify any members of someOtherStructB:

someOtherStructB.a = 9;
someOtherStructB.b = 12;

We only get an error on modifying b because b is declared const inside the struct itself:


clang-700.1.81:
error: read-only variable is not assignable
    someOtherStructB.b = 12;
    ~~~~~~~~~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only member 'b'
     someOtherStructB.b = 12;
                        ^

Declaring an entire instance of a struct with a const qualifier is the same as creating a special-purpose copy of the struct with all members specified as const. If you don’t need a 100% const struct, you can const only specific members in individual struct declarations where necessary.

Pointer

const pointers is where the fun starts.

One `const`

Let’s use a pointer to an integer as an example.

uint64_t bob = 42;
uint64_t const *aFour = &bob;

Since this is a pointer, we have two storage complications happening here:

the data storage of bob
the pointer storage of aFour, a pointer to bob

So, what can we do with aFour? Let’s try a few things.

Do you think dereferencing the const pointer allows for modification?

*aFour = 44;


clang-700.1.81:
error: read-only variable is not assignable
    *aFour = 44;
    ~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location '*aFour'
     *aFour = 44;
            ^

How about just updating the const pointer without modifying the pointed-to value?

aFour = NULL;

That actually works and is perfectly valid. We declared uint64_t const * meaning just “pointer to const data,” but the pointer itself is not const (also note: const uint64_t * has the same meaning).

How can we make both the data and the pointer const at the same time? Introducing: double const.

Two `const`

Let’s add another const and see how things play out.

uint64_t bob = 42;
uint64_t const *const anotherFour = &bob;

*anotherFour = 45;
anotherFour = NULL;

What’s the result?


clang-700.1.81:
error: read-only variable is not assignable
    *anotherFour = 45;
    ~~~~~~~~~~~~ ^
error: read-only variable is not assignable
    anotherFour = NULL;
    ~~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location '*anotherFour'
     *anotherFour = 45;
                  ^
error: assignment of read-only variable 'anotherFour'
     anotherFour = NULL;
                 ^

Ah ha! We successfully made the data and the pointer itself const.

What does `const *const` mean?

Meanings seem less obvious here.

Meanings are so wonky it’s actually recommended to read declarations backwards (or worse, spiral).

In this case, when read backwards², the declaration means:

uint64_t const *const anotherFour = &bob;

anotherFour is
- a const pointer (*const)
- to a const uint64_t (uint64_t const)

Given our “normal” syntax of just uint64_t const *anotherFour, read backwards, means:

aFour is
- a regular mutable pointer (*; meaning: the pointer itself can change)
- to const uint64_t data (uint64_t const; meaning: the data pointed to cannot change)

What did we just see?

An important distinction here: people typically call const uint64_t *bob a “const pointer,” but that is not what happens here. It’s actually “mutable pointer to const data.”

Intermission — Explaining C `const` declarations

But wait, there’s more!

We just saw how the introduction of a pointer gave us four const options for our declaration. We can:

Declare nothing const and allow updates to both pointer and pointed-to data
- ```
uint64_t *bob;
```
Declare only const data, but allow pointer to change
- ```
uint64_t const *bob;
```
- This is a common pattern for iterating over sequential data: advance to the next element by incrementing a pointer, but don’t allow the pointer to modify data.
Declare only const pointer, but allow data to change
- ```
uint64_t *const bob;
```
- Valid pointer values are always a scalar memory addresses (uintptr_t), so this const has the same effect as using scalar const with regular integer values, meaning: it’s okay if your implementation uses this const to qualify parameters but your function prototype doesn’t need to include it since this const protects a pointer address, but not pointed-to data.
Declare const data and const pointer allowing nothing to change after initial declaration
- ```
uint64_t const *const bob;
```

That’s with one pointer and two const, but what if we add another pointer?

Three `const`

One

How many ways can we annotate const with a double pointer?

Let’s do a quick sanity check.

uint64_t const **moreFour = &aFour;

Which of these operations are allowed given the above declaration?

**moreFour = 46;
*moreFour = NULL;
moreFour = NULL;


clang-700.1.81:
error: read-only variable is not assignable
    **moreFour = 46;
    ~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location '**moreFour'
     **moreFour = 46;
                ^

Only the first assignment failed because our declaration, when read backwards:

uint64_t const **moreFour = &aFour;

moreFour is
- a pointer (*)
- to a pointer (*)
- to const uint64_t storage (uint64_t const)

As we saw, the only operation we couldn’t complete is modifying the actual storage value. We successfully modified both the pointer and the pointed to pointer.

Two

What if we want to add another const one level deeper?

uint64_t const *const *evenMoreFour = &aFour;

Given the two const above³, what can we do now?

**evenMoreFour = 46;
*evenMoreFour = NULL;
evenMoreFour = NULL;


clang-700.1.81:
error: read-only variable is not assignable
    **evenMoreFour = 46;
    ~~~~~~~~~~~~~~ ^
error: read-only variable is not assignable
    *evenMoreFour = NULL;
    ~~~~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location '**evenMoreFour'
     **evenMoreFour = 46;
                    ^
error: assignment of read-only location '*evenMoreFour'
     *evenMoreFour = NULL;

Now we’re locked out from modifying twice because our declaration, when read backwards:

uint64_t const *const *evenMoreFour = &aFour;

evenMoreFour is
- a pointer (*)
- to a const pointer (*const)
- to const uint64_t storage (uint64_t const)

Three

We can do one better than two. Introducing: three const.

What if we want to lock down all changes to everything in a double pointer declaration?

uint64_t const *const *const ultimateFour = &aFour;

Now what can we (not) do?

**ultimateFour = 48;
*ultimateFour = NULL;
ultimateFour = NULL;


clang-700.1.81:
error: read-only variable is not assignable
    **ultimateFour = 46;
    ~~~~~~~~~~~~~~ ^
error: read-only variable is not assignable
    *ultimateFour = NULL;
    ~~~~~~~~~~~~~ ^
error: read-only variable is not assignable
    ultimateFour = NULL;
    ~~~~~~~~~~~~ ^

gcc-5.3.0:
error: assignment of read-only location '**ultimateFour'
     **ultimateFour = 46;
                    ^
error: assignment of read-only location '*ultimateFour'
     *ultimateFour = NULL;
                   ^
error: assignment of read-only variable 'ultimateFour'
     ultimateFour = NULL;
                  ^

Nothing worked! Success!

Here we go, one more time:

uint64_t const *const *const ultimateFour = &aFour;

ultimateFour is
- a const pointer (*const)
- to a const pointer (*const)
- to const uint64_t storage (uint64_t const)

Other Rules

It’s always safe to make any declaration const (if you don’t need to modify values)
- Any non-const data can be declared to a new const-only variable
  - Creating immutable references to mutable storage is always allowed
  - ```
  uint32_t abc = 123;
  uint32_t *thatAbc = &abc;
  uint32_t const *const immutableAbc = thatAbc;
```
- Be safe and const as many function parameters as you can
  - ```
  void trySomething(const storageStruct *const storage,
              const uint8_t *const ourData,
              const size_t len) {
    saveData(storage, ourData, len);
  }
```
- Make all input arguments as const as possible when you don’t need to modify data
const is only a compile time check. const vs. non-const doesn’t alter program behavior.
- const exists to help humans handle complexity a little easier.
  - helps self-document expected behavior of variables and parameters.
    - serves as easy maintenance guard if you forget what should vs. shouldn’t be modified in the future.
- const can always be hacked around by explicit casting or memory copying (or worse: memory corruption changing values out from under you).
  - Your compiler, at its discretion, may also choose to place any const declarations in read-only storage, so if you attempt to hack around the const blocks, you could get undefined behavior.

Hacks

Casting Hackery

What if you’re clever and make a non-const pointer to const storage like:

const uint32_t hello = 3;
uint32_t *getAroundHello = &hello;
*getAroundHello = 92;

Your compiler will complain you dropped const, but with just a warning⁴ you can disable⁵:


clang-700.1.81:
warning: initializing 'uint32_t *' (aka 'unsigned int *')
         with an expression of type 'const uint32_t *' (aka 'const unsigned int *')
         discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
    uint32_t *getAroundHello = &hello;
              ^                ~~~~~~

gcc-5.3.0:
warning: initialization discards 'const' qualifier from pointer target type
         [-Wdiscarded-qualifiers]
     uint32_t *getAroundHello = &hello;
                                ^

Since this is C, you can cast away the const qualifier and dismiss the warning (also violating the initial const constraint):

uint32_t *getAroundHello = (uint32_t *)&hello;

Now you have no warnings on compile because you’ve explicitly told your compiler to ignore the actual type of &hello in favor of your re-interpretation as uint32_t *.

Memory Hackery

What if a struct has const members, but you modify struct storage after declaration?

Let’s define two structs only differing in member constness.

struct exampleA {
    int64_t a;
    uint64_t b;
};

struct exampleB {
    int64_t a;
    const uint64_t b;
}; 

const struct exampleA someStructA = {.a = 3, .b = 4};
struct exampleB someOtherStructB = {.a = 3, .b = 4};

Try to copy someOtherStructB onto const someStructA.

memcpy(&someStructA, &someOtherStructB, sizeof(someStructA));

Does that work?


clang-700.1.81:
warning: passing 'const struct aStruct *' to parameter of type 'void *'
         discards qualifiers
         [-Wincompatible-pointer-types-discards-qualifiers]
    memcpy(&someStructA, &someOtherStructB, sizeof(someStructA));
           ^~~~~~~~~~~~

gcc-5.3.0:
In file included from /usr/include/string.h:186:0:
warning: passing argument 1 of '__builtin___memcpy_chk' discards 'const' qualifier
         from pointer target type [-Wdiscarded-qualifiers]
     memcpy(&someStructA, &someOtherStructB, sizeof(someStructA));
            ^
note: expected 'void *' but argument is of type 'const struct aStruct *'

Nope, that doesn’t work because the prototype⁶ for memcpy is:

void *memcpy(void *restrict dst, const void *restrict src, size_t n);

memcpy doesn’t allow const pointers to be passed as dst argument because dst is mutated by the copy (and someStructA is const).

Though, const parameter validation is only enforced by the function prototype. Will the compiler complain if we use a non-entirely-const struct with some internal const fields as dst?

What happens if we attempt to copy const someStructA into not-const-but-has-one-const-member someOtherStructB?

memcpy(&someOtherStructB, &someStructA, sizeof(someOtherStructB));

The default compiler prototype check now passes and we get no warnings with this memcpy, even though we are overwriting a const member of a not-entirely-const struct.

Conclusion

Stop mutating values unnecessarily. Be strict with making the implementation of your programs match the mental model of how you expect your programs to actually work.

The less data you change, the less you’ll break the world.

-Matt — ☁mattsta

Try it Yourself

#include <stddef.h> /* gives us NULL */
#include <stdint.h> /* gives us exact integer width types */

int main(void) {
    uint64_t bob = 42;

    const uint64_t *aFour = &bob;
    /* uint64_t const *aFour = &bob; */

    *aFour = 44; /* NO */
    aFour = NULL;

    const uint64_t *const anotherFour = &bob;
    /* uint64_t const *const anotherFour = &bob; */

    *anotherFour = 45; /* NO */
    anotherFour = NULL; /* NO */

    const uint64_t **moreFour = &aFour;
    /* uint64_t const **moreFour = &aFour; */

    **moreFour = 46; /* NO */
    *moreFour = NULL;
    moreFour = NULL;

    const uint64_t *const *evenMoreFour = &aFour;
    /* uint64_t const *const *evenMoreFour = &aFour; */

    **evenMoreFour = 47; /* NO */
    *evenMoreFour = NULL; /* NO */
    evenMoreFour = NULL;

    const uint64_t *const *const ultimateFour = &aFour;
    /*  uint64_t const *const *const ultimateFour = &aFour; */

    **ultimateFour = 48; /* NO */
    *ultimateFour = NULL; /* NO */
    ultimateFour = NULL; /* NO */

    return 0;
}

also meaning: it’s perfectly safe to pass const scalars to functions using them as non-const parameters because the functions have no way to modify your original scalar values↩︎
These are cases where it can be easier to write uint64_t const * instead of const uint64_t * because both declarations have the exact same behavior, but, when reading backwards, you don’t have to pretend your declaration is circular when the const qualifier is after your type.↩︎
This also proves, definitely, the correct pointer syntax is type *name and not type* name and especially not type * name because when you add const, the pointer attaches to the next const, not the previous qualifier. e.g.
WRONG
```
uint64_t const* const* evenMoreFour; /* pointers are each attached
                                        to the wrong const */
```
The first const above belongs to uint64_t, not to the first pointer! The second const above belongs to the first pointer, not the second pointer!
CORRECT
```
uint64_t const *const *evenMoreFour; /* const properly attributed
                                        for reverse reading. */
```
↩︎
well, one non-standardized warning flag per compiler model, so your build process would need many redundant flags for cross-compiler compatibility to disable these warnings↩︎
Reminder: const is only a compile time check; it does not change program behavior if you manage to violate const constraints (any more than altering any other value changes your program behavior), but it will probably alter your expectations of what is actually going on. Also: your compiler may place const data declarations in read only code segments, and hacking around those const blocks would cause undefined behavior.↩︎
Also note the restrict keyword in the memcpy() prototype. restrict means “this pointer’s data doesn’t overlap with any other data in the current scope” which is the definition of how memcpy() expects to process its parameters.
If you do need to copy memory from the same space onto itself, that’s what memmove() is for, and the prototype for memmove() notably does not have any restrict qualifiers:
```
void *memmove(void *dst, const void *src, size_t len);
```
↩︎

Article Analysis

Summary

This article explores the C `const` qualifier, demonstrating its role in preventing variable modification at compile time through various data types like scalars, arrays, structs, and pointers. It highlights how `const` enforces immutability and explains common compiler errors and potential workarounds when attempting to bypass these restrictions, ultimately advocating for strict adherence to `const` for improved code robustness.

Content Scores

Metric	Min	Max	Mean	Median	Total
Humor	1	3	2.00	2.0	36
Helpfulness	4	9	8.28	9.0	149
Aggression	0	1	0.28	0.0	5
Spiciness	0	2	0.28	0.0	5

Chunk-by-Chunk Analysis

Chunk Summary

This article introduces the concept of `const` in C, demonstrating how it prevents modification of variables at compile time through illustrative code examples and compiler error messages.

Chunk Ratings

Metric	Score	Reason
Humor	2	The title "So You Think You Can `Const`" is a playful pun on a song title, which adds a lighthearted touch, but the content itself is strictly instructional.
Helpfulness	6	The text begins to explain the basic `const` rule in C with a clear example and compiler error output, but it cuts off before fully developing the concept or providing more advanced scenarios.
Aggression	0	The text is purely informational and educational, lacking any aggressive or negative sentiment.
Spiciness	0	The content is professional and focused on technical explanation, with no offensive or provocative language.

Show Original Text

---
date: '2016-04-11'
frame: frame-front
frontTitle: So You Think You Can `Const`
panelsAll: panels-nonr
published: true
subframe: frame-article
title: So You Think You Can Const?
---

---
date: '2024-07-10'
published: false
title: Sytycc.Mattsrc
---

<link rel="stylesheet" type="text/css" href="/a2h"></link>

# So You Think You Can `const`

Think you you know all the `const` rules for C?  Think again.

Previously: *[How to C](/howto-c)*

## Basic `const`

### Scalar
You're familiar with simple `const` rule in C.

```c
const uint32_t hello = 3;
```

`const` on `hello` means *at compile time* your compiler verifies `hello` never changes.

If you try to modify or re-assign `hello`, your compiler stops you:

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    hello++;
<span class="ansi1 ansi32">    ~~~~~^
</span><span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    hello = 92;
<span class="ansi1 ansi32">    ~~~~~ ^
</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>increment of read-only variable '<span class="ansi1">hello</span>'
     hello++;
<span class="ansi1 ansi32">          ^</span>

Chunk Summary

The text explains that C compilers are flexible with `const` qualifiers on scalar parameters, allowing mismatches between prototypes and implementations because scalar arguments are passed by value and cannot be modified by the function.

Chunk Ratings

Metric	Score	Reason
Humor	1	The text is primarily technical documentation and contains no intentional humor. The single point could be interpreted as a mild attempt at wit.
Helpfulness	9	The text clearly explains the behavior of `const` qualifiers with scalar parameters in C, including the flexibility in prototype vs. implementation and the reasoning behind it. It provides actionable understanding for C programmers.
Aggression	0	The text is neutral and informative, with no trace of negativity, anger, or depression.
Spiciness	0	The text is entirely professional and informative, with no offensive or provocative content.

Show Original Text

<span class="ansi1 ansi31">error: </span>assignment of read-only variable '<span class="ansi1">hello</span>'
     hello = 92;
<span class="ansi1 ansi32">           ^</span>
</div>
</pre>

Additionally, C doesn't really care where `const` shows up as long as it's before your identifier, so `const uint32_t` and `uint32_t const` are identical:

```c
const uint32_t hello = 3;
uint32_t const hello = 3;
```

#### Prototypal Scalar Const

Compare the following function prototype versus implementation:

```c
void printTwo(uint32_t a, uint64_t b);

void printTwo(const uint32_t a, const uint64_t b) {
	printf("%" PRIu32 " %" PRIu64 "\n", a, b);
}
```

Will your compiler complain if `printTwo()` implementation has scalar `const` parameters but its prototype doesn't?

Nope.

It's perfectly okay to have mismatching prototype `const` qualifiers for scalar implementation arguments.

Why is this okay?  Pretty simple: there's no way your function can modify `a` or `b` outside of the function scope itself, so `const` has no impact on any callers of your function.  Your compiler is smart enough to know it will be *copying* the scalars `a` and `b`, so `const`-vs-not-`const` has no impact on the physical or mental models of your program here.

Your compiler won't care if you have mismatching `const` for any non-pointer or non-array parameters since those will be copied directly by value and the original values at the caller will always remain unmodified^[also meaning: it's perfectly safe to pass `const` scalars to functions using them as non-`const` parameters because the functions have no way to modify your original scalar values].

Chunk Summary

This text provides clear examples and explanations on how to utilize the `const` keyword in C for arrays and structs, including demonstrating compiler errors when attempting to modify `const`-qualified data.

Chunk Ratings

Metric	Score	Reason
Humor	1	The text is primarily technical and instructional, with no explicit attempts at humor. The mention of compiler errors might elicit a slight groan of recognition from programmers, but it's not intended as a joke.
Helpfulness	9	The text clearly explains how to use the `const` keyword with arrays and structs in C programming, providing concrete code examples and demonstrating compiler errors when `const` is violated. This is highly actionable information for developers.
Aggression	0	The text maintains a neutral and informative tone throughout. There is no expression of anger, negativity, or depression.
Spiciness	0	The text is entirely professional and educational, focusing on programming concepts without any offensive or inappropriate content.

Show Original Text


Though, your compiler *will* complain if you have mismatching `const` with pointer or array parameter data because then your function has the ability to manipulate pointed-to data passed in which must be agreed upon by the caller as well as the callee.

### Array

You can `const` an entire array declaration.
```c
const uint16_t things[] = {5, 6, 7, 8, 9};
```

`const` can still be after the type as well:
```c
uint16_t const things[] = {5, 6, 7, 8, 9};
```

If you try to modify `things[]`, your compiler stops you:

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    things[3] = 12;
<span class="ansi1 ansi32">    ~~~~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">things[3]</span>'
     things[3] = 12;
<span class="ansi1 ansi32">               ^</span>
</div></pre>

### Struct

#### Regular Struct

You can `const` an entire struct.
```c
struct aStruct {
    int32_t a;
    uint64_t b;
};

const struct aStruct someStructA = {.a = 3, .b = 4};
```

Or:
```c
struct const aStruct someStructA = {.a = 3, .b = 4};
```

If we try to modify any members of `someStructA`: 
```c
someStructA.a = 9;

Chunk Summary

The provided text explains that errors occur when attempting to modify members of `const` declared structs or `const` members within a struct, illustrating this with compiler error examples.

Chunk Ratings

Metric	Score	Reason
Humor	1	The text is primarily technical and informative. There are no attempts at humor or witty remarks.
Helpfulness	9	The text clearly explains why an error occurs when modifying a `const` struct member and provides practical code examples demonstrating this behavior and the distinction when only specific members are `const`.
Aggression	0	The text is neutral and objective, focusing on technical explanations without any negative or aggressive tone.
Spiciness	0	The text maintains a professional and factual tone, avoiding any offensive or inappropriate language.

Show Original Text

```

We get an error because `someStructA` is declared as `const`. We can't modify members after declaration.

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    someStructA.a = 9;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of member '<span class="ansi1">a</span>' in read-only object
     someStructA.a = 9;
<span class="ansi1 ansi32">                   ^</span>
</div></pre>


#### Internal `const` Struct

You can `const` individual members of a struct.
```c
struct anotherStruct {
    int32_t a;
    const uint64_t b;
}; 

struct anotherStruct someOtherStructB = {.a = 3, .b = 4}; 
```

If we try to modify any members of `someOtherStructB`: 
```c
someOtherStructB.a = 9;
someOtherStructB.b = 12;
```

We only get an error on modifying `b` because `b` is declared `const` inside the struct itself:

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    someOtherStructB.b = 12;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~~~~~~ ^</span>

Chunk Summary

This text explains how to use `const` qualifiers with C/C++ structs and pointers, illustrating the concepts with compiler error examples.

Chunk Ratings

Metric	Score	Reason
Humor	2	The text uses phrases like "where the fun starts" and asks rhetorical questions, indicating a slight attempt at humor, but it's primarily instructional.
Helpfulness	9	The text provides clear explanations and code examples for understanding `const` qualifiers with structs and pointers in C/C++, demonstrating the practical implications and compiler errors.
Aggression	1	The tone is generally neutral and informative, with no overt negativity or aggression present.
Spiciness	0	The content is strictly technical and educational, with no offensive or controversial material.

Show Original Text


gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only member '<span class="ansi1">b</span>'
     someOtherStructB.b = 12;
<span class="ansi1 ansi32">                        ^</span>
</div></pre>


Declaring an entire instance of a `struct` with a `const` qualifier is the same as creating a special-purpose copy of the struct with all members specified as `const`.  If you don't need a 100% `const` struct, you can `const` only specific members in individual `struct` declarations where necessary.
 
### Pointer

`const` pointers is where the fun starts.

#### One `const`
Let's use a pointer to an integer as an example.

```c
uint64_t bob = 42;
uint64_t const *aFour = &bob;
```

Since this is a pointer, we have *two* storage complications happening here:

- the data storage of `bob`
- the pointer storage of `aFour`, a pointer to `bob`

So, what can we do with `aFour`?  Let's try a few things.

Do you think dereferencing the `const` pointer allows for modification?
```c
*aFour = 44;
```

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    *aFour = 44;
<span class="ansi1 ansi32">    ~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">*aFour</span>'

Chunk Summary

This text explains the C/C++ `const` qualifier for pointers, demonstrating how to declare a pointer to constant data and a constant pointer to data with illustrative code examples and resulting compiler errors.

Chunk Ratings

Metric	Score	Reason
Humor	3	The humor is subtle, arising from the programmer's playful "double const" phrasing and the implied exasperation with compiler errors. It's not laugh-out-loud funny, but it adds a touch of personality.
Helpfulness	9	The text clearly explains the concept of `const` pointers in C/C++, differentiating between a pointer to constant data and a constant pointer to data. It provides practical code examples and highlights the compiler errors that result from violating these const qualifiers, making it very informative for developers.
Aggression	1	The tone is professional and educational. The use of compiler error messages, while negative in their own right, are presented factually as part of the explanation and do not convey personal anger or frustration in the writing itself.
Spiciness	0	The content is purely technical and educational, with no offensive or inappropriate language.

Show Original Text

     *aFour = 44;
<span class="ansi1 ansi32">            ^</span>
</div></pre>

How about just updating the `const` pointer without modifying the pointed-to value?

```c
aFour = NULL;
```

That actually works and is perfectly valid.  We declared `uint64_t const *` meaning just "pointer to const data," but the pointer *itself* is not const (also note: `const uint64_t *` has the same meaning).

How can we make both the *data* and the *pointer* `const` at the same time?  Introducing: double const.

#### Two `const`

Let's add *another* const and see how things play out.

```c
uint64_t bob = 42;
uint64_t const *const anotherFour = &bob;

*anotherFour = 45;
anotherFour = NULL;
```

What's the result?

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    *anotherFour = 45;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~ ^
</span><span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    anotherFour = NULL;
<span class="ansi1 ansi32">    ~~~~~~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">*anotherFour</span>'
     *anotherFour = 45;
<span class="ansi1 ansi32">                  ^</span>

Chunk Summary

The text explains a C/C++ compilation error related to assigning a read-only variable and clarifies the meaning of `const *const` declarations by recommending reading them backwards.

Chunk Ratings

Metric	Score	Reason
Humor	3	The text employs mild humor with phrases like "Ah ha!", "wonky," and the reference to the "spiral" method, which adds a touch of levity to a technical explanation.
Helpfulness	8	The text clearly explains the error in the code snippet and then delves into the meaning of `const *const` in C/C++ declarations, providing a helpful explanation and a link for further reading.
Aggression	0	The text is purely informative and educational, with no negative or aggressive language.
Spiciness	0	The content is professional and technical, with no offensive or inappropriate language.

Show Original Text

<span class="ansi1 ansi31">error: </span>assignment of read-only variable '<span class="ansi1">anotherFour</span>'
     anotherFour = NULL;
<span class="ansi1 ansi32">                 ^</span>
</div></pre>

*Ah ha!*  We successfully made the data *and* the pointer itself `const`.

##### What does `const *const` mean?

Meanings seem less obvious here.

Meanings are so wonky it's actually recommended to *[read declarations backwards](https://stackoverflow.com/questions/1143262/what-is-the-difference-between-const-int-const-int-const-and-int-const)* (or worse, *[spiral](http://c-faq.com/decl/spiral.anderson.html)*).

In this case, when read backwards[^rotund], the declaration means:

```c
uint64_t const *const anotherFour = &bob;
```
- `anotherFour` is
	- a `const` pointer (`*const`)
	- to a `const` `uint64_t` (`uint64_t const`)

Given our "normal" syntax of just `uint64_t const *anotherFour`, read backwards, means:

- `aFour` is
	- a regular mutable pointer (`*`; meaning: the pointer itself can change)
	- to `const` `uint64_t` data (`uint64_t const`; meaning: the data pointed to cannot change)

[^rotund]: These are cases where it can be easier to write `uint64_t const *` instead of `const uint64_t *` because both declarations have the _exact same_ behavior, but, when reading backwards, you don't have to pretend your declaration is circular when the `const` qualifier is after your type.

##### What did we just see?

An important distinction here: people typically call `const uint64_t *bob` a "const pointer," but that is **not**

Chunk Summary

The text explains C's `const` declarations with single pointers, outlining four distinct patterns for modifying pointer and pointed-to data, and then introduces the complexity of double pointers.

Chunk Ratings

Metric	Score	Reason
Humor	1	The text uses mild conversational phrasing like "But wait, there's more!" and "Let's do a quick sanity check," which offer a slight touch of personality but are not overtly humorous.
Helpfulness	9	The text clearly explains the four different ways to use `const` with a single pointer in C, providing examples and explanations for each. It then transitions into discussing double pointers and poses questions, indicating a pedagogical approach.
Aggression	0	The text is neutral and informative, with no indication of negativity, anger, or depression.
Spiciness	0	The text maintains a professional and educational tone, avoiding any offensive or inappropriate language.

Show Original Text

what happens here.  It's actually "mutable pointer to `const` data."

### Intermission — Explaining C `const` declarations

_But wait, there's more!_

We just saw how the introduction of a pointer gave us *four* `const` options for our declaration.  We can:

- Declare nothing `const` and allow updates to both pointer and pointed-to data
	- ```c
uint64_t *bob;
```
- Declare only `const` data, but allow pointer to change
	- ```c
uint64_t const *bob;
```
	- This is a common pattern for iterating over sequential data: advance to the next element by incrementing a pointer, but don't allow the pointer to modify data.
- Declare only `const` pointer, but allow data to change
	- ```c
uint64_t *const bob;
```
    - Valid pointer values are always a scalar memory addresses (`uintptr_t`), so this `const` has the same effect as using scalar `const` with regular integer values, meaning: it's okay if your implementation uses this `const` to qualify parameters but [your function prototype doesn't need to include it](#prototypal-scalar-const) since this `const` protects a pointer address, but not pointed-to data.
- Declare `const` data and `const` pointer allowing nothing to change after initial declaration
	- ```c
uint64_t const *const bob;
```

That's with *one* pointer and *two* const, but what if we add another pointer?

### Three `const`

#### One
How many ways can we annotate `const` with a double pointer?

Let's do a quick sanity check.
```c
uint64_t const **moreFour = &aFour;
```

Which of these operations are allowed given the above declaration?
```c
**moreFour = 46;
*moreFour = NULL;
moreFour = NULL;
```

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >

Chunk Summary

This text explains C pointer assignment errors with `const` qualifiers, illustrating how multiple `const` keywords affect mutability.

Chunk Ratings

Metric	Score	Reason
Humor	2	The text contains a slight attempt at humor with the phrase "our declaration, when read backwards" and the question posed in the "Two" section. However, it's primarily technical in nature.
Helpfulness	9	The text clearly explains a C programming error related to pointer declarations and `const` qualifiers, providing specific examples and explanations of what is and isn't assignable.
Aggression	0	The text is purely technical and educational, with no aggressive or negative sentiment present.
Spiciness	1	The footnote mentioning "WRONG" pointer syntax is a mild, though generally accepted, form of critical commentary in a technical context, but it's not offensive.

Show Original Text

clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    **moreFour = 46;
<span class="ansi1 ansi32">    ~~~~~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">**moreFour</span>'
     **moreFour = 46;
<span class="ansi1 ansi32">                ^</span>
</div></pre>

Only the first assignment failed because our declaration, when read backwards:

```c
uint64_t const **moreFour = &aFour;
```
- `moreFour` is
	- a pointer (`*`)
	- to a pointer (`*`)
	- to `const` `uint64_t` storage (`uint64_t const`)

As we saw, the only operation we *couldn't* complete is modifying the actual storage value.  We successfully modified both the pointer and the pointed to pointer.


#### Two
What if we want to add another `const` one level deeper?

```c
uint64_t const *const *evenMoreFour = &aFour;
```

Given the two `const` above[^dif], what can we do now?

[^dif]: This also proves, definitely, the correct pointer syntax is `type *name` and **not** `type* name` and **especially not** `type * name` because when you add `const`, the pointer attaches to the *next* `const`, not the previous qualifier.  e.g.<br />
**WRONG**
```c
uint64_t const* const* evenMoreFour; /* pointers are each attached

Chunk Summary

This text demonstrates the correct application of `const` with nested pointers in C++ and illustrates the compiler errors that occur with incorrect usage.

Chunk Ratings

Metric	Score	Reason
Humor	3	The text uses mild humor through the use of "evenMoreFour" as a variable name, which implies a slightly exasperated tone regarding complex C++ syntax.
Helpfulness	9	The text clearly explains a common C++ pointer and const declaration pitfall, provides a correct example, and shows the resulting compiler errors, making it highly informative for developers.
Aggression	0	The text is purely technical and educational, with no negative or aggressive sentiment present.
Spiciness	0	The text maintains a professional and informative tone, avoiding any offensive or inappropriate content.

Show Original Text

                                            to the wrong const */
```
The first `const` above belongs to `uint64_t`, **not** to the first pointer!  The second `const` above belongs to the first pointer, **not** the second pointer!<br />
**CORRECT**
```c
uint64_t const *const *evenMoreFour; /* const properly attributed
                                            for reverse reading. */
```


```c
**evenMoreFour = 46;
*evenMoreFour = NULL;
evenMoreFour = NULL;
```

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    **evenMoreFour = 46;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~~ ^
</span><span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    *evenMoreFour = NULL;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~ ^</span>

gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">**evenMoreFour</span>'
     **evenMoreFour = 46;
<span class="ansi1 ansi32">                    ^</span>

Chunk Summary

This text demonstrates how multiple `const` qualifiers in C pointer declarations restrict modification of the pointed-to data, the pointer itself, and the pointer to the pointer, illustrated with compiler error examples.

Chunk Ratings

Metric	Score	Reason
Humor	3	The text uses a playful tone with phrases like "Now we're locked out" and "We can do one better than two," adding a light touch to technical explanations.
Helpfulness	9	The text clearly explains the concept of multiple `const` qualifiers in C pointers with practical code examples and the resulting compiler errors, offering valuable insight for programmers.
Aggression	1	The tone is generally instructive and slightly whimsical, not displaying any negativity or hostility.
Spiciness	0	The content is purely technical and educational, with no offensive or inappropriate language.

Show Original Text

<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">*evenMoreFour</span>'
     *evenMoreFour = NULL;
</div></pre>

Now we're locked out from modifying twice because our declaration, when read backwards:

```c
uint64_t const *const *evenMoreFour = &aFour;
```
- `evenMoreFour` is
	- a pointer (`*`)
	- to a `const` pointer (`*const`)
	- to `const` `uint64_t` storage (`uint64_t const`)


#### Three
We can do one better than two.  Introducing: three `const`.

What if we want to lock down all changes to everything in a double pointer declaration?

```c
uint64_t const *const *const ultimateFour = &aFour;
```

Now what can we (not) do?
```c
**ultimateFour = 48;
*ultimateFour = NULL;
ultimateFour = NULL;
```

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    **ultimateFour = 46;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~~ ^
</span><span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    *ultimateFour = NULL;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~~ ^
</span><span class="ansi1 ansi31">error: </span><span class="ansi1">read-only variable is not assignable</span>
    ultimateFour = NULL;
<span class="ansi1 ansi32">    ~~~~~~~~~~~~ ^</span>

Chunk Summary

The text presents GCC errors from attempting to modify a `const` pointer declaration, explains the `const` qualifiers, and offers general advice on using `const` correctly in C.

Chunk Ratings

Metric	Score	Reason
Humor	3	The "Nothing worked! Success!" phrase injects a mild, self-deprecating humor common in technical contexts.
Helpfulness	8	The text clearly identifies the GCC errors related to assigning to read-only locations and provides the specific C code causing the issue. It then explains the nature of the `const` declarations and offers general advice on using `const` safely.
Aggression	1	The tone is frustrated but not angry or hostile. It expresses a common developer sentiment of hitting a wall.
Spiciness	0	The text is professional and focuses on a technical problem without any offensive or inappropriate content.

Show Original Text


gcc-5.3.0:
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">**ultimateFour</span>'
     **ultimateFour = 46;
<span class="ansi1 ansi32">                    ^</span>
<span class="ansi1 ansi31">error: </span>assignment of read-only location '<span class="ansi1">*ultimateFour</span>'
     *ultimateFour = NULL;
<span class="ansi1 ansi32">                   ^</span>
<span class="ansi1 ansi31">error: </span>assignment of read-only variable '<span class="ansi1">ultimateFour</span>'
     ultimateFour = NULL;
<span class="ansi1 ansi32">                  ^</span>
</div></pre>

Nothing worked!  Success!

Here we go, one more time:

```c
uint64_t const *const *const ultimateFour = &aFour;
```
- `ultimateFour` is
	- a `const` pointer (`*const`)
	- to a `const` pointer (`*const`)
	- to `const` `uint64_t` storage (`uint64_t const`)

## Other Rules

- It's **always** safe to make any declaration `const` (if you don't need to modify values)
	- Any non-`const` data can be declared to a new `const`-only variable
		- Creating immutable references to mutable storage is always allowed
		- ```c
uint32_t abc = 123;
uint32_t *thatAbc = &abc;
uint32_t const *const immutableAbc = thatAbc;
```
	- Be safe and `const` as many function parameters as you can

Chunk Summary

The text explains the utility of `const` in C for developers, while also detailing methods and consequences of bypassing its compile-time checks.

Chunk Ratings

Metric	Score	Reason
Humor	2	The text contains a few lighthearted remarks such as "clever and make a non-const pointer" and "hackery," but it is primarily informative rather than humorous.
Helpfulness	8	The text clearly explains the purpose and benefits of using `const` in C programming, including its role in documentation and maintenance, and it also highlights the limitations and potential pitfalls of `const`.
Aggression	0	The tone of the text is neutral and informative, with no discernible negativity or aggression.
Spiciness	2	The text uses terms like "hackery" and "hacking around" to describe bypassing `const` qualifiers, which implies a slight informal or edgy tone, but it remains professional and is not offensive.

Show Original Text

		- ```c
void trySomething(const storageStruct *const storage,
                  const uint8_t *const ourData,
                  const size_t len) {
    saveData(storage, ourData, len);
}
```
	- Make all input arguments as `const` as possible when you don't need to modify data
- `const` is **only** a compile time check.  `const` vs. non-`const` doesn't alter program behavior.
	- `const` exists to help humans handle complexity a little easier.
		- helps self-document expected behavior of variables and parameters.
			- serves as easy maintenance guard if you forget what should vs. shouldn't be modified in the future.
	- `const` can always be hacked around by explicit casting or memory copying (or worse: memory corruption changing values out from under you).
        - Your compiler, at its discretion, may also choose to place any `const` declarations in read-only storage, so if you attempt to hack around the `const` blocks, you could get undefined behavior.


## Hacks

### Casting Hackery
What if you're clever and make a non-`const` pointer to `const` storage like:

```c
const uint32_t hello = 3;
uint32_t *getAroundHello = &hello;
*getAroundHello = 92;
```

Your compiler will complain you dropped `const`, but with just a warning^[well, one non-standardized warning flag per compiler model, so your build process would need many redundant flags for cross-compiler compatibility to disable these warnings] you can disable^[Reminder: `const` is **only** a compile time check; it does not change program behavior if you manage to violate `const` constraints (any more than altering any other value changes your program behavior), but it will probably alter your expectations of what is actually going on.  Also: your compiler may place `const` data declarations in read only code segments, and hacking around those `const` blocks would cause undefined behavior.]:

Chunk Summary

The text explains a C compiler warning about discarding const qualifiers and offers a solution with a cast, also introducing the concept of memory hackery with structs.

Chunk Ratings

Metric	Score	Reason
Humor	2	The text uses the phrase "Memory Hackery" which is a mild attempt at humor within a technical context.
Helpfulness	8	The text clearly identifies a C compiler warning related to discarding const qualifiers and provides a direct code solution to suppress it, explaining the implications.
Aggression	0	The text is purely informational and technical, with no negative sentiment or emotion expressed.
Spiciness	1	The text mentions "violating the initial const constraint" and "hackery," which implies a slight bending of strict rules, but it's not offensive or unprofessional.

Show Original Text


<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi35">warning: </span><span class="ansi1">initializing 'uint32_t *' (aka 'unsigned int *')
         with an expression of type 'const uint32_t *' (aka 'const unsigned int *')
         discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]</span>
    uint32_t *getAroundHello = &amp;hello;
<span class="ansi1 ansi32">              ^                ~~~~~~</span>

gcc-5.3.0:
<span class="ansi1 ansi35">warning: </span>initialization discards '<span class="ansi1">const</span>' qualifier from pointer target type
         [-Wdiscarded-qualifiers]
     uint32_t *getAroundHello = &amp;hello;
<span class="ansi1 ansi32">                                ^</span>
</div>
</pre>

Since this is C, you can cast away the `const` qualifier and dismiss the warning (also violating the initial `const` constraint):

```c
uint32_t *getAroundHello = (uint32_t *)&hello;
```

Now you have no warnings on compile because you've explicitly told your compiler to ignore the actual type of `&hello` in favor of your re-interpretation as `uint32_t *`.

### Memory Hackery

What if a `struct` has `const` members, but you modify `struct` storage after declaration?

Let's define two structs only differing in member `const`ness.

```c
struct exampleA {

Chunk Summary

The text illustrates an attempt to copy data into a `const` variable using `memcpy`, which results in compiler warnings about discarding qualifiers.

Chunk Ratings

Metric	Score	Reason
Humor	1	The text presents a technical problem and solution in a straightforward manner, with no attempts at humor.
Helpfulness	8	The text clearly presents a C code snippet, poses a question about its functionality, and then shows compiler warnings from two different compilers (Clang and GCC) for the attempted operation. This is highly informative for a programmer trying to understand why their code might not behave as expected.
Aggression	0	The text is purely technical and factual, displaying no negative emotions or aggression.
Spiciness	0	The content is strictly technical code and compiler output, with no offensive or unprofessional elements.

Show Original Text

    int64_t a;
    uint64_t b;
};

struct exampleB {
    int64_t a;
    const uint64_t b;
}; 

const struct exampleA someStructA = {.a = 3, .b = 4};
struct exampleB someOtherStructB = {.a = 3, .b = 4}; 
```

Try to copy `someOtherStructB` onto `const` `someStructA`.

```c
memcpy(&someStructA, &someOtherStructB, sizeof(someStructA));
```

Does that work?

<pre class="ansi2html-content"><div class="body_foreground body_background" style="font-size: normal;" >
clang-700.1.81:
<span class="ansi1 ansi35">warning: </span><span class="ansi1">passing 'const struct aStruct *' to parameter of type 'void *'
         discards qualifiers
         [-Wincompatible-pointer-types-discards-qualifiers]</span>
    memcpy(&amp;someStructA, &amp;someOtherStructB, sizeof(someStructA));
<span class="ansi1 ansi32">           ^~~~~~~~~~~~</span>

gcc-5.3.0:
In file included from <span class="ansi1">/usr/include/string.h:186:0</span>:
<span class="ansi1 ansi35">warning: </span>passing argument 1 of '<span class="ansi1">__builtin___memcpy_chk</span>' discards '<span class="ansi1">const</span>' qualifier
         from pointer target type [-Wdiscarded-qualifiers]
     memcpy(&amp;someStructA, &amp;someOtherStructB, sizeof(someStructA));
<span class="ansi1 ansi32">            ^</span>

Chunk Summary

This text explains why `memcpy` fails with a `const` pointer and introduces `memmove` as an alternative, while also exploring the nuances of `const` type checking in C.

Chunk Ratings

Metric	Score	Reason
Humor	3	The text uses a casual "Nope, that doesn't work" which injects a slight informal tone, but it's primarily technical explanation rather than aiming for humor.
Helpfulness	9	The text clearly explains a common C programming error related to `memcpy` and `const` pointers, providing the correct prototypes for `memcpy` and `memmove` and explaining the implications of the `restrict` keyword. It also includes a practical example and a follow-up question about compiler behavior.
Aggression	1	The tone is informative and direct, with a slight sense of mild frustration implied by the "Nope, that doesn't work" opening, but it's not aggressive.
Spiciness	1	The content is purely technical and professional, with no offensive or inappropriate language used.

Show Original Text

<span class="ansi1 ansi36">note: </span>expected '<span class="ansi1">void *</span>' but argument is of type '<span class="ansi1">const struct aStruct *</span>'
</div>
</pre>

Nope, that doesn't work because the prototype[^res] for `memcpy` is:
```c
void *memcpy(void *restrict dst, const void *restrict src, size_t n);
```

[^res]: Also note the `restrict` keyword in the `memcpy()` prototype.  `restrict` means "this pointer's data doesn't overlap with any other data in the current scope" which is the definition of how `memcpy()` expects to process its parameters.
\
If you do need to copy memory from the same space onto itself, that's what `memmove()` is for, and the prototype for `memmove()` notably does not have any `restrict` qualifiers:
```c
void *memmove(void *dst, const void *src, size_t len);
```

`memcpy` doesn't allow `const` pointers to be passed as `dst` argument because `dst` is mutated by the copy (and `someStructA` is `const`).

Though, `const` parameter validation is only enforced by the function prototype. Will the compiler complain if we use a non-entirely-`const` struct with some internal `const` fields as `dst`?

What happens if we attempt to copy `const` `someStructA` into not-`const`-but-has-one-`const`-member `someOtherStructB`?

```c
memcpy(&someOtherStructB, &someStructA, sizeof(someOtherStructB));
```

The default compiler prototype check now *passes* and we get no warnings with this `memcpy`, even though we are overwriting a `const` member of a not-entirely-`const` struct.

Chunk Summary

This guide uses C code examples to illustrate the importance of immutability and strict adherence to mental models in programming, advising against unnecessary value mutation.

Chunk Ratings

Metric	Score	Reason
Humor	2	The text uses a mild, dry wit with the repetition of "Four" to emphasize the concept of immutability and pointer constness in C. It's not overtly humorous but has a subtle playfulness.
Helpfulness	9	The text provides a clear and practical explanation of immutability using C code examples, specifically demonstrating const correctness with pointers. It offers actionable advice and illustrates common pitfalls.
Aggression	0	The tone is professional and advisory, with no discernible negativity or anger.
Spiciness	0	The text is entirely professional and avoids any offensive or provocative language.

Show Original Text



## Conclusion

Stop mutating values unnecessarily.  Be strict with making the implementation of your programs match the mental model of how you expect your programs to actually work.

The less data you change, the less you'll break the world.

-[Matt](mailto:matt@matt.sh) — [☁mattsta](https://github.com/mattsta?tab=repositories)

## Try it Yourself
```c
#include <stddef.h> /* gives us NULL */
#include <stdint.h> /* gives us exact integer width types */

int main(void) {
    uint64_t bob = 42;

    const uint64_t *aFour = &bob;
    /* uint64_t const *aFour = &bob; */

    *aFour = 44; /* NO */
    aFour = NULL;

    const uint64_t *const anotherFour = &bob;
    /* uint64_t const *const anotherFour = &bob; */

    *anotherFour = 45; /* NO */
    anotherFour = NULL; /* NO */

    const uint64_t **moreFour = &aFour;
    /* uint64_t const **moreFour = &aFour; */

    **moreFour = 46; /* NO */
    *moreFour = NULL;
    moreFour = NULL;

    const uint64_t *const *evenMoreFour = &aFour;
    /* uint64_t const *const *evenMoreFour = &aFour; */

    **evenMoreFour = 47; /* NO */
    *evenMoreFour = NULL; /* NO */
    evenMoreFour = NULL;

    const uint64_t *const *const ultimateFour = &aFour;
    /*  uint64_t const *const *const ultimateFour = &aFour; */

    **ultimateFour = 48; /* NO */
    *ultimateFour = NULL; /* NO */

Chunk Summary

This code snippet initializes a variable to NULL and returns 0, with a brief comment indicating negation.

Chunk Ratings

Metric	Score	Reason
Humor	1	The comment "/* NO */" is a brief, slightly informal indication of negation, which can be perceived as a subtle, dry humor by those familiar with programming contexts.
Helpfulness	4	The code snippet itself shows a variable being initialized to NULL and a return statement. The comment "/* NO */" is not inherently helpful in understanding the code's logic or purpose.
Aggression	0	The text is purely functional code with a neutral comment, showing no signs of negativity, anger, or depression.
Spiciness	0	The content is strictly technical code and a non-offensive comment, demonstrating a complete lack of offensive material.

Show Original Text

    ultimateFour = NULL; /* NO */

    return 0;
}
```

So You Think You Can const

Basic const

Scalar

Prototypal Scalar Const

Array

Struct

Regular Struct

Internal const Struct

Pointer

One const

Two const

What does const *const mean?

What did we just see?

Intermission — Explaining C const declarations

Three const

One

Two

Three

Other Rules

Hacks

Casting Hackery

Memory Hackery

Conclusion

Try it Yourself

So You Think You Can `const`

Basic `const`

Internal `const` Struct

One `const`

Two `const`

What does `const *const` mean?

Intermission — Explaining C `const` declarations

Three `const`