4 ms·

So if I understand the author, const function arguments can just have const-ness cast away inside the function, so it's really much closer to a type hint than a

• haberman 10y ago
  The key distinction is not variable vs function argument, but rather const variable vs pointer-to-const. If you have "const int x" (as a local variable, global variable, or function parameter) then there is no valid way to modify x's value. But if you have "const int* y" (as a local variable, global variable, or function parameter), you can always cast away const and mutate as long as the original variable (the one "y" points to) wasn't declared const.
• deleted 10y ago
  [deleted]
• kbart 10y ago
  "casting away const-ness is undefined" No, it's not. That's the whole point why compiler can't optimize it away. You can often see ("char *") casts from static "strings" in legacy APIs and libraries calls, because original authors didn't know or didn't care how to use const correctly (or at all). I, personally, use const a lot throughout my C code, when you get it, it makes debugging so much easier.
  • x0x0 10y ago
    you skipped the first clause of my sentence -- if a variable is declared const, casting away const-ness is undefined is that not true?
    • ynik 10y ago
      The cast itself is not undefined. It's completely valid to use a non-const pointer to a const variable for reading that variable (this is actually quite common when interacting with libraries that are not const-correct). Undefined behavior only occurs when the const variable is being modified.
    • eternal_july 10y ago
      To reinforce the sibling comment's point: A very common pattern is when a const variable resides in non-writable memory (happens all the time in embedded), - if you attempt to write to it, you trigger a fault. So if you cast away constness to conform to some API and then read the value, everything is fine (aside from questionable API design, of course). Modifying the value is another story, though.
    • TorKlingberg 10y ago
      Yes, if a variable is declared const, casting away const-ness from a pointer to it and then writing to it is undefined.
    • adrianratnapala 10y ago
      I think it is only modifying that non-const value that is undefined. If you use a nominally mutable value in a read-only way, then you are OK. This is important because older libs that ignore (or abuse) const will often do read-only access to a char* or something. A nice example is that POSIX defines int execv(const char *path, char *const argv[]); That definition takes a constant pointer to variable chars! Worse, some people use the same signature for `main()` and also for libraries that parse `argv`. But none of them are actually allowed to vary those chars under Unix.
    • kbart 10y ago
      Your first part was irrelevant: if you cast away const, of course variable must have been const in first place. As other have already mentioned, casting itself is not an undefined behavior (and sometimes even have legitimate reasons, mentioned in my earlier post). On the other hand, trying to modify const variable though non-const pointer is undefined behavior. P.S. if you downvoted to disagree with this (on my parent post), please provide an opposite example, because as a C programmer, I would really be interested to be proven wrong on this matter.
      • x0x0 10y ago
        No, it could be mutable variable referenced/accessed (not sure of the right word here) in a function via either a reference-to-const or a pointer-to-const. It seems highly non-intuitive to me that casting away constness works differently depending on whether the variable was defined const or not, but if that's the rules, that's the rules.
• cygx 10y ago
  Mutability of a variable and const qualification of the target type of the pointer used to store its address are independent, and language semantics really only care about the former.
• caf 10y ago
  It's just that the actual const-ness is a property of the object itself, not something imbued by the lvalue used to access the object.