Thread: const qualifier used on a function argument

the bottom line for const qualification is that the compiler *will not* allow you alter a const object though it *will* allow you to convert it to a non-const object - whatever you do with it after that is undefined - if the data is stored in read-only memory an access violation might occur, if not, probably nothing. the important thing is that conversion should be reserved for situations where is can't be avoided and there is a very good reason for doing so in the first place.

> I do not change str inside func. Why does gcc give me a warning?
While str[0] = 'a' would get you another warning about trying to modify a const, s[0] = 'a' would be just fine (you've now subverted the const-ness).

> Does it complain because after I assign str to s, *str can be changed outside func?
No, it's because s lacks a const qualifier.
as in
const char *s;
But then I think making s a global is just clouding the issue.

> And does this unmodifiability refer to actual unmodifiability or potential unmodifiability?
It doesn't matter

Code:

char msg[] = "a writable string";
func( msg );
func( "a string constant" );

All that you're saying is that func() won't cause the string to be modified, that is to say the variable msg will not change as a result of calling func().

> But does it matter whether I actually use that ability or not?
Well that depends doesn't it - do you really want it to be const or not.
There's no point declaring things const if you're just going to remove the const later on just because you can. Presumably, if you go to the trouble of declaring it const, then you'd be expecting a warning if you were about to lose const again.

> I never actually change *array inside the function!
No, but the caller function through the returned pointers of helper could do.

>> Is this prohibition refer to the actual change or potential change?

both. you can't *directly* modify a const identifier nor can you *implicitly* convert it to a non-const identifier. I say 'identifier' because 'object' implies the *thing* itself - const qualification really has less to do with what actually happens to an object than how the object is accessed through the identifiers associated with it. in other words, it is not a protection mechanism so much one of type checking.

Originally Posted by Salem

> And does this unmodifiability refer to actual unmodifiability or potential unmodifiability?
It doesn't matter

> I never actually change *array inside the function!
No, but the caller function through the returned pointers of helper could do.

I think your remarks illustrate exactly why I am confused. In the first part, you say "it does not matter" but in the last part, what you really say, if I understand it correctly, is it does matter - the unmodifiability refers to potential unmodifiability. (The word "could" is used - the caller function could possibly change the string value but it may not actually do it.) The fact seems to be that even if I actually do not change the value of the string parameter - neither inside nor outside the function, qualifying the parameter with const would give a gcc warning if I assign the pointer to another pointer that is not const-qualified, even though I do not actually change the string value through the const-unqualified pointer. The mere potential, or possibility, that I may change the string value via the second pointer is sufficient to cause a gcc warning.

Originally Posted by Sebastiani

>> Is this prohibition refer to the actual change or potential change?

both. you can't *directly* modify a const identifier nor can you *implicitly* convert it to a non-const identifier. I say 'identifier' because 'object' implies the *thing* itself - const qualification really has less to do with what actually happens to an object than how the object is accessed through the identifiers associated with it. in other words, it is not a protection mechanism so much one of type checking.

Would it be clearer if I say "const qualification really has less to do with what _actually_ happens to an object than how the object _may possibly be_ accessed through the identifiers associated with it."?
And since the compiler, not the run-time, is responsible for checking the const-ness, the compiler is more conservative and treats any such possiblility, though not realized during runtime, as a violation of the const-ness and give a warning.
So correct me if I am wrong, all those "won't be changed", "may not be changed", "cannot be changed" things do not refer to any actual change, but refer to any possible change that may happen at run-time which the compiler is not able to tell for sure.

Ah, I see what you're getting at (I think)

Code:

void func ( char **helper, const char *array ) {
  helper[0] = array;
}
int main ( ) {
  char msg[] = "hello world";
  char *helper[2];

  func( &helper, msg );
  helper[0][0] = 'H';  // modifies msg[0]

  func( &helper, "string constant" );
  helper[0][0] = 'S';  // segfault?
  return 0;
}

In the first instance, the const should just be diagnosing local attempts to modify the variable. The input array isn't const to begin with, so it should be reasonable to expect to be able to modify it afterwards via the return result. Unfortunately, the const is a 'sticky' attribute and it propagates through assignments.

In the second instance, it's saying that the input is really const and that should be propagated to other pointers as well. Indeed, it would be nice to diagnose helper[0][0] = 'S' at compile time rather than at run-time (or worse, some random crash much later on).

Ideally of couse, we would have had
const char *helper[2];
func( &helper, "string constant" );
But then the compiler would have complained about the first parameter losing const!

It's like we need
void func ( char **helper, char *array );
void func ( const char **helper, const char *array );
but C doesn't have anything like that kind of overloading ability to be able to resolve all the possible meanings.

1. I gave up on the initHelper() example after I read comp.lang.c FAQ 11.10 (http://c-faq.com/questions.html). There is simply too much complication for me to handle and it is not a good example to highlight the issue which i want to investigate.
2. I construct a simpler example:

Code:

char * func ( const char *array ) {
  char *array1 = array;
  //array[0] = 'H';
  return array1;
}

int main ( ) {
  char *msg;
  char *msg1;

  msg = malloc(20);
  sprintf(msg, "hello world");
  msg1 = func(msg);
}

As the code stands now, gcc issues a warning: " warning: initialization discards qualifiers from pointer target type"
Well, a warning is just a warning that something _may_ go wrong. So, I guess any one can issue a warning about anything. It does not mean that what I do violate the C Standard. (And I think I do not violate the C Standard. Though I do not have the C Standard on hand, C FAQ 1.20b implies that it is not inconsistent with C Standard if I const-ify a function parameter and never actually change it inside the function - it says "many functions declare parameters which are pointers to const data, and doing so documents (and tends to enforce) the function's promise that it [i.e. the function]won't modify the pointed-to data in the caller." So the (only) promise is that the pointed-to data is not changed inside the function. It does not care whether the pointed-to data is actually changed outside the function. gcc can give all the warnings it wants (and this warning is probably an over-reaction) but apparently the const does not propogate outside the function - at least that's what the C FAQ suggests, as I understand.)
If I remove the const from func's parameter, then there is no warning and the program executes fine, as anticipated.
If I uncomment the "array[0] = 'H';", then gcc issues the above warning plus an error: "error: assignment of read-only location". This error is understandable and expected (had it not for the wording of the warning).
Now what I do not understand is the wording of the gcc warning: initialization discards qualifiers from pointer target type. It seems to suggest that gcc discards/ignores the const qualifier. If that's the case, then there would and should not be an error when I try to change h to H!
Any insight?

Can anyone check on the official C Standard to see what exactly it says about 'const'?

Originally Posted by hzmonte

Now what I do not understand is the wording of the gcc warning: initialization discards qualifiers from pointer target type. It seems to suggest that gcc discards/ignores the const qualifier. If that's the case, then there would and should not be an error when I try to change h to H!
Any insight?

The compiler is trying to do what you are telling it to do. In the initialization, you are taking a pointer to const and assigning its value to a non-const pointer. This may result in undefined behavior, and the compiler informs you of possible issues.

It's up to you to look at the suspect code and determine whether or not you actually do modify the pointed-to contents, or rather to instead change the type to better match the intention. I see the diagnostic as saying, "Hey, shouldn't array1 be a const char *?"

Originally Posted by hzmonte

Can anyone check on the official C Standard to see what exactly it says about 'const'?

An archive of C89, but it's rather dry. C99 isn't much more fun. [edit]But I believe the key wording is as such:

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.

Originally Posted by Dave_Sinkula

The compiler is trying to do what you are telling it to do. In the initialization, you are taking a pointer to const and assigning its value to a non-const pointer. This may result in undefined behavior, and the compiler informs you of possible issues.

I am inclined to disagreeing that discarding the const qualifier is what I am telling the compiler to do, if that's what you mean. Yes, I am taking a pointer to const and assigning its value to a non-const pointer, but that does not mean the const qualifier has to be discarded. I located the May 5, 2005 Committee Draft of the C Standard (http://www.open-std.org/jtc1/sc22/wg...ocs/n1124.pdf). Paragraph 5 of Section 6.7.3 (page 109) has the exact sentence as you cited in the C89 Standard. It implies that if there is no (actual) attempt made to modify the pointed-to data, then the use of the const qualifier is okay. And if the use of the const qualifier is allowed by the C Standard, then there is no reason to discard the qualifier. So, no, I did not tell gcc to discard the const qualifier. And what results in undefined result is an (actual) attempt to modify the pointed-to data, not taking a pointer to const and assigning its value to a non-const pointer. If there is no attempt to modify the data, then there is no undefined result, even though I take a pointer to const and assigning its value to a non-const pointer. That is, as long as I stop short of attempting to modify the data, I am in compliance with the C Standard as far as const is concerned.
And gcc does more than informing me of the possible issues, it discards the const qualifier! And if it discards the const qualifier, then apparently a subsequent modification of the pointed-to data would be allowed! That's the inconsistency - on one hand, it discards the const, on the other hand, it issues an error disallowing me to modify the data.

Originally Posted by Dave_Sinkula

I see the diagnostic as saying, "Hey, shouldn't array1 be a const char *?"

Well, if the warning says something like what you see as saying, then I am perfectly satisfied. But again, it issues a warning AND discards the const qualifier. I guess discarding the qualifier is at the discretion of the compiler. C Standard does not prohibit a compiler from doing that. But if the compiler discards the const, can it turn around and prohibit me from modifying the data?

[Edit] It is like you are late in paying your mortgage. The bank takes your late payment - but still declares a default and forecloses your house. Can the bank have the cake and eat it too? Isn't that a bit too harsh?
I am also wondering whether gcc is overreacting by issuing a warning (not to mention its discarding the const qualifier). As explained above, taking a pointer to const and assigning its value to a non-const pointer is not a violation of the C Standard. Further, an actual attempt to modify the data can be detected by gcc, which issues an error. So, a warning (not to mention the discarding of the const) appears to be unnecessary.[/Edit]

there are lots of things not prohibited by the C standard, but do cause undefined behaviour.

First just consider it bad style to assign a const variable to a non const variable.
Second, on some systems variables declared as const might be put into a read-only section of the executable or are put on an EPROM. So if you get a non const pointer to that data and later try to change it the system will probably crash.

third, the compiler might be able to see in this instance that the non-const variable never changes value, but things are often way harder in C to detect. you can have pointers everywhere, pointers to pointers, const data coming from a dynamic library etc. Maybe a system could be implemented by gcc to detect all possible const to non-const violations, but that would be really hard if not impossible.
So gcc decides to give the warning at the time it's easiest to detect and where the bad style programming actually occurs.

so if you think you really know what you are doing and that never ever in the future the non const will change what it points to just cast! s = (char *)s1; imo just a source for hard to find bugs but be my guest