2

I am reading a book that has the following code:

int list_ins_next(List *list, ListElmt *element, const void *data) {
    ListElmt           *new_element;
    /*  Allocate storage for the element.*/
    if ((new_element = (ListElmt *)malloc(sizeof(ListElmt))) == NULL)
        return -1;
    /*  Insert the element into the list.*/
    new_element->data = (void *)data;
    /* and so on */
}

As we see, the function gets const void *data as one of the arguments.

Why is it re-cast in the line: new_element->data = (void *)data; ?

Additional information:

/*  Define a structure for linked list elements. */
typedef struct ListElmt_ {
    void               *data;
    struct ListElmt_   *next;
} ListElmt;

/*  Define a structure for linked lists.*/
typedef struct List_ {
    ListElmt           *head;
    ListElmt           *tail;
} List;
Improve this question
5
  • 3
    It's removing the const, telling the compiler that even though the function promised not to modify memory pointed at by data, actually it's totally fine to do so and therefore the pointer can be stored in a non-const value which makes no such guarantees. OR... the pointer is non-const BUT will be treated as const ("pinky swear"). Without the cast, this would be an error. It's a little bit of bad behavior, really, but this happens a lot in C. Commented Dec 2, 2021 at 3:22
  • 2
    This is not necessarily fine. Imagine if you pass an actual const pointer to the function. It would basically remove the const specifier. So if the code that uses this linked list does not keep track of this themselves, it might hide some potential bugs. Like for example when a developer nicely keeps track of const string literals. They wouldn't get a warning and later on some other code might access the pointer to the string literal and attempt to modify it. That would no longer cause warnings to be emitted but could trigger an access violation. Commented Dec 2, 2021 at 3:29
  • 1
    Indeed. What I meant is the cast is asserting that it's "fine". The warning/error that the cast is bypassing is there precisely to pick up accidental misuse. And the existence of the cast is there to assure the compiler that the rules will be obeyed despite it looking otherwise dodgy. Failure to deliver on that promise will result in undefined behavior. Commented Dec 2, 2021 at 3:31
  • 1
    @paddy why not post it as an answer? Commented Dec 2, 2021 at 4:02
  • Sure. I've done so. In a kind of story-telling way. That's where my head's at today. Commented Dec 2, 2021 at 4:45

1 Answer 1

Reset to default
1

Without the cast, and with sufficient compiler warning levels enabled, your compilation would fail with something like:

warning: assignment discards 'const' qualifier from pointer target type

What this means is that the following assignment is breaking some rules:

new_element->data = data;  // <-- danger!

What's wrong?

Well, the message tells you that a 'const qualifier' is being discarded as a result of the assignment. Let's unpack what that implies.

The variable data has the type const void*, which means the memory it points at should never be modified as a result of following that pointer. In other words, the function list_ins_next is not allowed to do anything that will result in that memory being changed.

So now, the list node that the pointer is being stored in does not make such promises. It has a data member of type void* which means anyone following the pointer stored in the list is allowed to modify the memory it points to.

Some memory really is not allowed to be modified. String literals are an example. If you have the string "hello" in your program, that's actually stored in memory somewhere as part of the code. And you can have a pointer: const char* hello = "hello"; ... but you really should not drop the const and start messing with that data.

Do you see the problem? If this were allowed to pass, then the function list_ins_next might be unknowingly breaking the rules. Even though it's not allowed to modify memory pointed to by data, it is storing that pointer in a structure not bound by such restrictions. Later on, someone using that structure could happily go and use data as if it were non-const, without realizing it's supposed to be const.

Analogy time (naughty)

Imagine you went on holiday, and had someone look after your house. Before you left, you made them promise not to touch your top-shelf whisky. You return a week later, the whisky is gone. You ask them why they broke their promise, and they insist that they really didn't touch it, but they did invite a friend over and gave them full permission to drink it all.

Obviously, this is untenable behavior and something we want to avoid. Being in this situation could provoke a violent, irrational response that could damage friendships, property, and bodies. In computer land, we call that Undefined Behavior.

Anyway, let's put aside my anxieties about stewardship of expensive single malt, and return to talking about code.

Good behavior

The issue here is that the compiler wants to stop us from accidentally making mistakes, wherever it can. It rightly warns us: hey, this is bad, you might be using this wrong.

Now, back to why the cast is there. It is a little hard to say for sure without more context. What I will say is that the cast is making a promise:

Dear C compiler, by this cast I solemnly swear that I'm not going to break the rules, or maybe I might break the rules but I really really REALLY know what I'm doing and all of the ramifications, so please let's just pretend that this const pointer is not const.

Thanks <3 - A. C. Programmer.

This is the best case scenario. If the way that this list is used will really not result in modifications to the data, OR if the data didn't really need to be const (but for some reason the insert function made it const) then all is well. It's now the programmer's responsibility to keep their word.

Analogy time (nice)

You can actually trust your friend with your whisky. While you're away, they looked through the collection, but only to catalogue it. They had a friend around, and they spent time researching where it all came from and finding out information about distilleries. You return from holiday and it's all right where you left it, safe and secure.

Next to it there's a notebook containing detailed information about what you have and how much money you probably wasted on booze. There's also a note asking if you'll consider organizing a whisky tasting session one day.

Bad behavior

However, this sadly is not the most common reason for casting away const.

What we see very frequently is addition of a cast by someone who just wanted to get around a compiler error without fully understanding it. The compiler said "whoah buddy, hold on" and the programmer said "please shut up so I can run my code".

And, you know... I get the feeling that the author of this book might possibly fall into the latter category, but I won't outright claim this because I haven't seen the full context of the code example to comment on why it was written this way.

At face value, either the list should be storing const data or the insert function should be accepting non-const data. End of story.

Summary

We commonly say "casts hide bugs". Keep this in mind. When you cast, do it with intent. Do it because you know it's valid, not just because the language will let you do it. C will happily let you hold a nailgun to your foot and pull the trigger.

Anyways, I hope this lengthy explanation has helped somewhat, even if I can't peer inside the head of whoever wrote that code.

And that really touches on another topic -- if you cast away a const, you should probably at the very least somewhere have a comment in the code explaining why. Because one day, someone is gonna read it and ask why. And that person might even be the same person who wrote the code years prior.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.