Quote:
> >> Continuing the previous topic.
> >> The pointer to the literal (*a) is meant to be passed to an function
> >> which
> >> takesa char * but not a char * const as argument. Is it still safe
> >> enough to assume that function is not going to do anything to the
> >> vunarable
> >> pointer?
> >> The original post is attach :
> >> -----------------------------------
> >> Hi all,
> >> I am wondering if the following code is OK. Well,
> >> it compiles and runs OK. What I am worrying about
> >> is the assignment from a macro to a. Is that OK?
> >> /////////////////////////////////////
> >> #include <stdio.h>
> >> #define DEFAULT_NAME "hello, there!"
> >> int main()
> >> {
> >> char *a;
> >> a = DEFAULT_NAME;
> >> ^^^^^^^^^^^^^^
> >> (void)puts(a);
> >> return 0;
> >> }
> > According to my information the argument to puts is typed as:
> > const char *
> > which is consistent with passing a pointer to a literal string.
> I am not talking about puts() but a third party function.
> > char * const
> > Is a different type -- the pointer is constant not what it points to.
Attempting to write to the string addressed by a invokes undefined
behaviour
so it would be nice to declare a with:
const char *a;
not:
char * const a;
which makes the pointer a constant rather than what it points to.
But (a) might later be used to point to a writable string and in this
case
needs to be declared:
char * a;
while the programmer keeps track of where it points and whether the
string
to which it points is writable.
Whether (a) while assigned to a literal string should ever be passed as
an argument to a function declared as expecting a char * argument rather
than a const char * argument is perhaps debatable. If the documentation
gives no indication that the function will not attempt to change the
string in the circumstances then it is certainly inadvisable.
But there can be situations that lead to complications as for example
in the library function strchr, which has its first argument declared as
const char * but then returns this pointer value as char * , so that the
unwary programmer could end up attempting to change a literal string via
the returned pointer without getting a compiler diagnostic. The return
value declaration is of course designed to cover the instance of strchr
being passed a pointer to a modifiable string. If one imagines
implementing the function strchr in the C language then the
implementation
needs to cast the const char * argument to (char *) for the the return
value.
Now an implementor faced with the need to define a similar function
might choose to deal with the dilemma by declaring the argument
as char * and avoid casting the return value. (Although following
the precedent established with strchr might be a better choice)
In regard to a pointer declared as:
char * const b;
I can see no problem in passing this to a function declared as taking
a char * argument as only the pointer value is passed, not the pointer
itself and the original pointer cannot in any case be changed by the
function.
Malcolm Kay
Is this a good idea? (cont)