apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] apr_getopt_long interface update and interleaving support
Date Sat, 25 Nov 2000 18:39:33 GMT
[ dropped SVN list; this really is just about APR here ]

On Sat, Nov 25, 2000 at 10:49:22AM -0500, Greg Hudson wrote:
>...
> Is a cast (implicit or explicit) really necessary if a const target
> doesn't change the storage features of the pointer?  I'm not sure;
> that gets into the vagaries of just what an ANSI C implementation is
> or is not allowed to do differently with pointers to const foo.  But
> practically speaking, we don't want callers of apr_initopts() to have
> to cast main()'s argv argument to avoid an incompatible type warning.
> (Having main() accept a "const char **argv" is just relegating the
> incompatible type faux pas to a place gcc won't currently warn about;
> it's still equally incorrect, and it's unreasonable for a library to
> require such a thing of its calling programs).

I disagree. The addition of const implies semantics about what the function
is going to do with the data. The lack of it says something else entirely.

The following code:

int main(int argc, char *argv[])
{
    ...
    apr_initopt(&os, pool, argc, (const char * const *)argv);
    ...
}

This is perfectly safe to do, and is not a burden on the caller.

We should not make APR conform to the vagaries of what the compiler will
auto-cast (e.g. just "char *const *"), but we should do what is Right. And
the right thing here is to say "we aren't changing that stuff; sorry about
the cast, but you can change your main() decl, or you can complain to the
GCC folks because the cast is safe".

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message