Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!wuarchive!wugate!uunet!mcsun!hp4nl!star.cs.vu.nl!maart
From: maart@cs.vu.nl (Maarten Litmaath)
Newsgroups: comp.std.c
Subject: Re: the "const" qualifier
Message-ID: <3728@solo10.cs.vu.nl>
Date: 16 Oct 89 16:28:14 GMT
References: <12239@cit-vax.Caltech.Edu> <11301@smoke.BRL.MIL>
Organization: V.U. Informatica, Amsterdam, the Netherlands
Lines: 22

gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
\...  Note that the
\first-level ignoring of qualifiers on the pointed-to types allows a
\(char *) argument to be passed without casting to a function declared as
\taking a (const char *) parameter, but the qualifier-ignoring does not
\occur at second or lower levels.
          ^^^^^^^^^^^^^^^^^^^^^^
Why?  (See below.)

\>	extern int execv(const char *path, const char **args);
\>... my understanding of such a prototype is that the
\>function will not change the characters pointed to by "path", or
\>by "args[0], args[1], ...".  Passing pointers that permit such
\>changes I would expect to be allowed (and is, for "path").
\
\You understand the meaning okay.  The problem ultimately stems from a
\slight overloading of semantics for "const".  [...]

Could you elaborate on this counter-intuitivity?
-- 
The UNIX Way of doing something [...] is to make it look as much like a filter
as possible.  (Richard O'Keefe)        | Maarten Litmaath (mcsun!botter!maart)