Live data from Hacker News

Const and Optimization in C

nullprogram.com

1–10 of 44 posts

Re: Const and Optimization in C

#2
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 anything else. However, if a variable is declared const, casting away const-ness is undefined. Is this about right? Yikes that's complex. I suppose the moral is casting away const-ness is a terrible idea.

Re: Const and Optimization in C

#5
post #2

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 anything else. However, if a variable is declared const, casting away const-ness is undefined. Is this about right? Yikes that's complex. I suppose the moral is casting away const-ness is a terrible idea.

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.

Re: Const and Optimization in C

#6
post #2

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 anything else. However, if a variable is declared const, casting away const-ness is undefined. Is this about right? Yikes that's complex. I suppose the moral is casting away const-ness is a terrible idea.

[deleted]

Re: Const and Optimization in C

#7
The C99 specification, in §6.7.3¶5, has one sentence just for this:

  If an attempt is made to modify an object defined with a   
  const-qualified type through use of an lvalue with non-
  const-qualified type, the behavior is undefined.
This is a separate question than whether the compiler can rely on the function prototype, but doesn't his definition of bar() invoke undefined behavior by this rule?

  void foo(const int *readonly_x) {
    int *x = (int *)readonly_x;  // cast away const
    (*x)++;
  }
I naively assumed that in the context of the bar() function, readonly_x is "an object defined with a const-qualified type", and that since the function modifies this "through use of an lvalue with non-const-qualified type", that bar() invokes undefined behavior. Or am I falsely equating "declaring an object" with "defining an object"?

The original x wasn’t const-qualified, so this rule didn’t apply. And there aren’t any rules against casting away const to modify an object that isn’t itself const.

Does the original x matter here, or just the readonly_x variable that is in scope of the function? In the language of the spec, are x and readonly_x the same object? Or two different objects of different types that happen to point to the same address? Is it certain that const-qualifiers on function arguments can be legally be ignored inside that function?

Re: Const and Optimization in C

#8
post #2

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 anything else. However, if a variable is declared const, casting away const-ness is undefined. Is this about right? Yikes that's complex. I suppose the moral is casting away const-ness is a terrible idea.

"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.

Re: Const and Optimization in C

#9
post #8
post #2

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 anything else. However, if a variable is declared const, casting away const-ness is undefined. Is this about right? Yikes that's complex. I suppose the moral is casting away const-ness is a terrible idea.

"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.

you skipped the first clause of my sentence --

if a variable is declared const, casting away const-ness is undefined

is that not true?

Re: Const and Optimization in C

#10
post #7

The C99 specification, in §6.7.3¶5, has one sentence just for this: If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non- const-qualified type, the behavior is undefined. This is a separate question than whether the compiler can rely on the function prototype, but doesn't his definition of bar() invoke undefined behavior by this rule? void foo(const int *read…

`readonly_x` is a non-constant object of type 'pointer to const int'. If `readonly_x` itself was const-qualified, it'd look like this: `const int* const readonly_x`.

This is a distinct object from whatever pointer the caller is passing in. But none of this matters to the special const rule -- that rule is not talking about the pointer object, but about the target object that the pointer is pointing to.

Post reply on HN