Re: [PATCH 3/3] Silence a compiler warning.
Julien Cristau <firstname.lastname@example.org> writes:
> On Fri, Jan 7, 2011 at 00:31:07 +0100, Ferenc Wagner wrote:
>> Ferenc Wagner <email@example.com> writes:
>>> - execvp("udhcpc", arguments);
>>> + /* execvp doesn't like const strings for no reason, so we can
>>> + cast away the const to suppress the compiler warning */
>>> + execvp("udhcpc", (char **)arguments);
>> Actually, I started to feel bad about this part. Maybe it would be
>> wiser to use non-const strings from the beginning? That would require a
>> larger patch, though... And ignoring the warning hasn't caused any
>> trouble yet. Does anybody know why execvp hates const strings?
> execvp takes 'char *const argv', not 'const char **argv'.
That's exactly why a cast is needed here (I could have written
char * const * just as well, the point is the constness of the char, not
that of the char*). I found out why this is so. Quoting
The argv and envp arrays of pointers and the strings to which
those arrays point shall not be modified by a call to one of the exec
functions, except as a consequence of replacing the process image.
The statement about argv and envp being constants is included to
make explicit to future writers of language bindings that these
objects are completely constant. Due to a limitation of the ISO C
standard, it is not possible to state that idea in standard C.
Specifying two levels of const- qualification for the argv and
envp parameters for the exec functions may seem to be the natural
choice, given that these functions do not modify either the array of
pointers or the characters to which the function points, but this
would disallow existing correct code. Instead, only the array of
pointers is noted as constant. [...]
I found the answer at
So the cast is actually safe after all, but some reference should
probably be put into the comment.