const pointer parameter assigned to a local variable inside a function

Code:

---

void func1(const int* p, int i)
{
  int *q = p;
  if (*q==i)
  printf("very good");
}

---

I have to qualify the declaration of q with 'const' in order to avoid a gcc warning. Why? By declaring *p a const, I am saying nothing inside the function modifies *p, and indeed nothing does. So why does gcc give me
warning: initialization discards qualifiers from pointer target type
? Why does gcc discard the const-ness of *p? Yes, the function _may_ attempt to change *p through q, but the fact is it does not. And now gcc drops the const and actually the function now can change the value of *p!
Now I can change *p through q and gcc does not complain about assigning a value to a read-only memory (though still with that "discards qualifiers " warning):

Code:

---

void func1(const int* p, int i)
{
  int *q = p;
  *q = i;
}

---

Quote:

---

Why does gcc discard the const-ness of *p?

---

Because you tell it to.

Quote:

---

Originally Posted by Dave_Sinkula

Code:

---

const int *q = p;
}

---

---

That was exactly what I said: "I have to qualify the declaration of q with 'const' in order to avoid a gcc warning." And my question is: why? Do I misunderstand what "const" means?
To make it more complicated, now I have this code:

Code:

---

const int * func1(const int* p, int i)
{
  const int *q = p;
  if (*q==i)
    printf("very good");
  return p;
}

---

In the same spirit that I have to const-ify *q, I need to const-ify the return value of the function. That looks weird. And now if I have this:

Code:

---

int main()
{
  int *j;
  *j = 1;
  j = func1(j, 2);
  printf("*j=%d\n", *j);
  *j = 4;
}

---

The compiler again gives me that warning. And this time I cannot avoid it because I need to change *j. I can't const-ify *j.

If you mean to change something, don't make it const.

[edit]And this is UB:

Code:

---

  *j = 1;

---

Quote:

---

Originally Posted by Dave_Sinkula

Because you tell it to.

---

Did the C standard says one cannot assign a const pointed-to value (i.e. const *p) to another pointer (i.e. *q), or risk a warning? It appears to me that the only rule regarding const is that *p is not modified, and in this case it is not modified. So I should not get this warning. Am I right?

You can lie to the compiler to shut it up if you want, but this may be hazardous to your program's health.

Quote:

---

Originally Posted by Dave_Sinkula

If you mean to change something, don't make it const.

[edit]And this is UB:

Code:

---

  *j = 1;

---

---

I am forced to make it const! Based on my understanding of C, I should not be required to const-ify q, and that means I would not be foreced to const-ify the return value.

Quote:

---

Originally Posted by Dave_Sinkula

You can lie to the compiler to shut it up if you want, but this may be hazardous to your program's health.

---

My question remains: Where in the C standard that says one cannot assign a const pointed-to value (i.e. const *p) to another pointer (i.e. *q)? Forget about lying to the compiler. If the compiler conforms with C, then it would not give this unnecessary warning, and nobody needs to lie to it. Is my understanding about the C standard wrong? Does it have a rule that says one cannot assign a const pointed-to value (i.e. const *p) to another pointer (i.e. *q)?

First you promise the compiler you're not going to modify what is pointed to by p. And then you break the promise and say, "To heck with that, I"ll modify what I want!", by saying that what q points to is modifiable. Gcc says, "Uh, take another look."

Sh!t. Gimme a minute (or so). I think the standard says something like, go ahead, but it's UB...

[edit]

Quote:

---

Originally Posted by 6.7.3p5

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.

---

[edit=2]So this is the point at which you are giving license to UB:

Code:

---

int *q = p;

---

Frankly, I'd like the compiler to tell me where I'm about to screw up.

OK, I found this on the web:

If a pointer is declared as const, it can only be assigned another pointer declared as const. If the pointer is a parameter to a function and you want to assign it to some other pointer within that function (e.g., a local variable) then the local variable must also be const.

I do not know whether the standard actually says this, or it is an interpretation of what the standard says. So, the warning has nothing to do with whether a const parameter is actually modified or not. It simply prohibits a const pointer to be assigned to a non-const pointer, even though the non-const pointer does not in fact change the pointed-to value. C is simply too lazy to check; it just outlaws it to save the effort, I guess.

You're asking your poor compiler, and the poor compiler writers, to make sure that you're not a total idiot. They try their best to warn you when you may be doing something stupid, but they don't forbid you from shooting yourself in the foot. Such is the nature of a language that assumes you know what you are doing.

Such a restriction seems to produce some unintended undue inconvenience to the programmer in the following case:

Code:

---

typedef int t_compare_func(const void *, const void *);

struct node *tree_search(struct node *root, const void *keyy, t_compare_func *comp)
{
  struct node *cur_item;
  int result;
  if (root == NULL) return NULL;
  cur_item = root;
  while (cur_item != NULL) {
      result = (*comp)(cur_item->key, keyy);
      if (result == 0)
        break;
      else if (result > 0)
        cur_item = cur_item->left;
      else
        cur_item = cur_item->right;
  }
  return cur_item;
}

---

Here, I traverse the tree to find a node whose key member is the same as keyy. And the node found is returned. Nothing in the tree is ever modified. So naturally I would like to const-ify root. But then I am forced to also const-ify cur_item. And the return value also has to be const-ifed as a consequence. Now, (part of) the tree in the calling function cannot be modified! Therefore I have to give up const-ifying root even though nothing in the function modifies the tree. Can I avoid this side effect? Have I just found a legitimate use of const_cast here? O, const_cast is available in C++ only. I guess I need to just cast root like:
cur_item = (struct node *)root;
if I decalre root as a const parameter. Right?

Ah, the real question.

You can pass a non-const qualified value to a function with a const-qualified value. Going up doesn't hurt things, going down does.

But since I can't compile your snippet, I'll refrain from commenting further. [It's getting late for me.]

[edit]Do you intend to (potentially) modify root? If so, don't tell the compiler you won't. And the same goes for any aliases you may create.

Quote:

---

Originally Posted by hzmonte

I guess I need to just cast root like:
cur_item = (struct node *)root;
if I decalre root as a const parameter. Right?

---

Lying is lying.

Do you see what is wrong here?

Code:

---

result = (*comp)(cur_item->key, keyy);

---

Quote:

---

Originally Posted by Dave_Sinkula

You can pass a non-const qualified value to a function with a const-qualified value. Going up doesn't hurt things, going down does.

---

Are you referring to "root"? I do not quite understand what you mean by passing a non-const qualified value to a function with a const-qualified value. Are you saying I can declare root in the calling function as a non-const variable, and decalre root as a const param in the called function? That's what I am trying to do; but the compiler doesn't let me.

Quote:

---

Originally Posted by Dave_Sinkula

Do you intend to (potentially) modify root? If so, don't tell the compiler you won't. And the same goes for any aliases you may create.

---

I do not intend to modify root in the search function. It is just a search; nothing needs to be modified.

Here you say you root might be modified:

Code:

---

typedef int t_compare_func(const void *, const void *);

struct node *tree_search(struct node *root, const void *keyy, t_compare_func *comp)
{
  struct node *cur_item;
  int result;
  if (root == NULL) return NULL;
  cur_item = root;
  while (cur_item != NULL) {
      result = (*comp)(cur_item->key, keyy);
      if (result == 0)
        break;
      else if (result > 0)
        cur_item = cur_item->left;
      else
        cur_item = cur_item->right;
  }
  return cur_item;
}

---

It might even be written like this:

Code:

---

struct node *tree_search(struct node *root, const void *keyy, t_compare_func *comp)
{
  int result;
  if (root == NULL) return NULL;
  while (root != NULL) {
      result = (*comp)(&root->key, keyy);
      if (result == 0)
        break;
      else if (result > 0)
        root = root->left;
      else
        root = root->right;
  }
  return root;
}

---

[edit]Bah. It's late, I need to get some sleep.
[edit=2]Why not just post the actual code and describe the issues? You'd likely get faster results that way.

I don't see how root might be modified in the first case. The value of teh pointer itself, root, is not changed. The stuff pointed to by root is not changed either.
root is not changed in the first case but root is changed in the second case, I think.
And that's the actual code. Here is the node, for the sake of completeness:

Code:

---

struct node {
  node *parent, *left, *right;
  void *key, *data;
};

---

The function calling tree_search is not important. One can just
gcc -c this file, and the gcc warning still shows up.

http://groups.google.com/group/comp....d10534a16d4760

Okay, not as tired now. [I stand corrected; and I blame my poor post on cheap American beer.]

I'd say use the cast on the return value if you don't choose to const-qualify the return value. Or else const-qualify the return value and cast the return value in the calling function. Programmer's choice.

I don't know that I'd call this undue inconvenience. I'd consider it like adding break to a switch statement's cases -- 97% of the time it's what you want to do (like not having the cast), but there is that 3% remaining (like this, where you'd need the cast somewhere to avoid the warning).