d3x0xr
5/30/2016 2:23:00 PM
my point isn't even in typecasting, no typecast operator considered, as
typecasting allows the programmer to break all rules without warning or
error.
The case is, if i start writing routines that accept const char *...
then I can definatly safely pass "blah" to it, as a const char *.
if the routine is written to take a 'char*' then there are warnings
given when converting from the const char * to the char *.
So, I modify the routines to take const char *... but then eventually I
end up with a routine that takes the address of one of these
parameters... either as a char const *const * or a char const **, both
appropriate to taking the address of a const char * to pass to the
routine.
The deeper one goes with making code correct and declaring const char *
where the code definatly does not modify the content of the string, the
more trouble one has. If I had left everything as 'char*' and left the
const off, I would not be having this discussion...
Actually, the point that started this was taking all this wonderful C
code and compiling it wilth a C++ compiler which definately FORBIDS char
* = const char *. So, the parameters had to change to have a const
modifier where const data was passed such as "xyzzy".
Then, coming back to the C compiler, I get assaulted by warnings.
Ben Bacarisse:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>
>> d3x0xr said:
>>
>>> ---- Section 1 ----
>>>
>>> ------
>>> x.c
>>>
>>> int main( void )
>>> {
>>> char **a;
>>> char const *const *b;
>>> b = a; // line(9)
>>> }
>>
>> Consider:
>>
>> char foo = 'F';
>> char bar = 'B';
>> char *baz = &foo;
>> char **quux = &baz;
>> char const * const * eric;
>>
>> eric = quux; /* erroneous, and equivalent to your code */
>>
>> The compiler ought to be able to know for sure, because eric is a
pointer to
>> a const pointer to char, that *eric will not change. But because you
can do
>> this at any time:
>>
>> *quux = &bar;
>>
>> it becomes possible for legal code to subvert the constness of *eric,
and
>> the compiler won't like that even a little bit.
>
> This problem comes from two issues interacting:
>
> 1) The standard forbids certain dangerous conversion involving
> qualified types; and
> 2) To make things easy the rule forbids some safe conversion like the
> one give.
>
> The rule in the standard is designed to prevent modification of a
> const like this:
>
> int main(void)
> {
> const char foo = 'F';
> char *p;
> const char **cp = (const char **)&p; // force with cast
> *cp = &foo;
> *p = 'B';
>
> printf("c = %c\n", foo);
> return EXIT_SUCCESS;
> }
>
> Note that the compiler wants to be able to assume the foo can't
change
> (and maybe more importantly the programmer wants to assume that!) but
> if it allowed the assignment I forced with the cast, the const foo
can
> be changed, silently.
>
> To keep things simple, the standard says:
>
> 6.3.2.3:
>
> [2] For any qualifier q, a pointer to a non-q-qualified type may be
> converted to a pointer to the q-qualified version of the type; the
> values stored in the original and converted pointers shall compare
> equal.
>
> and then:
>
> 6.7.3 Type qualifiers
>
> [9] For two qualified types to be compatible, both shall have the
> identically qualified version of a compatible type; the order of
> type qualifiers within a list of specifiers or qualifiers does not
> affect the specified type.
>
> which, I think, allows common (safe) usages, forbids dangerous usages
> as above but also rules out certain safe combinations involving more
> than one level of indirection.
>
> --
> Ben.