Greg Stein wrote:
"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".
I'd just like to point out that this has nothing to do with GCC. The
standard requires a diagnostic.
But yes, the cast is sa
On Fri, Nov 24, 2000 at 05:10:08PM -0600, Karl Fogel wrote:
> Greg Stein <[EMAIL PROTECTED]> writes:
> > So... by stating the parameter is "const char * const *argv", we are saying
> > what we intend to do (or not do) with the arguments. And I think we really
> > ought to treat it as if those const
On Fri, Nov 24, 2000 at 05:13:07PM -0600, Karl Fogel wrote:
> By the way, regarding the renaming of `apr_option_t':
>
> APR doesn't seem to be too careful with namespaces anyway
True, but "apr_option_t" is awfully generic. Options for what? Sockets?
The type name has changed since this message :
[ 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 jus
> Const doesn't change the type (storage size) of anything. So a
> callee can *always* add a const qualifier to its parameters, as long
> as it then keeps that promise to never modify the data.
This rule is too expansive.
A parameter of type "pointer to const foo" is always compatible with
an ar
Karl Fogel wrote:
I confess I don't understand the nuance of these `const' usages.
The code needs to permute argv; if it can't, we'll have to change the
interface, right? If Greg H has to cast internally to get something
he can permute, then we might as well not require a const on the
castee in th
Greg Hudson <[EMAIL PROTECTED]> writes:
> It wasn't "const char *const *argv" before because a "char **"
> argument is not compatible with such a parameter, and C programs
> canonically take "char **argv", not "const char *const *argv". I'm
> not sure if it's even valid C to silently change from c
> so I went for clarity and renamed it `apr_longopt_t'
I'm sorry to have disappeared, but I think this really needs to change
back (or to something else; I had picked apr_getopt_option_t).
Something that specifies both long and short options should not be
called "longopt".
Karl Fogel wrote:
> Haven't committed (and won't) until we figure out what's going on with
> the `const's, though. :-)
Well, I take that back. Can't stay online much longer, and have a
feeling that any further tweaks will be minor, so I committed the
change. Greg H, commit those changes to the S
Well, just to be utterly clear, that diagram should better be:
argv +
|
|
V
[pointer0 , pointer1 , pointer2 , pointer3, ]
| | | |
| |
By the way, regarding the renaming of `apr_option_t':
APR doesn't seem to be too careful with namespaces anyway
("apr_make_hash", for example), so I went for clarity and renamed it
`apr_longopt_t', since it's something use when you're specifically
doing long option parsing, not just any old option
Greg Stein <[EMAIL PROTECTED]> writes:
> So... by stating the parameter is "const char * const *argv", we are saying
> what we intend to do (or not do) with the arguments. And I think we really
> ought to treat it as if those const qualifiers were on there.
I confess I don't understand the nuance
On Fri, Nov 24, 2000 at 07:50:34PM -0500, Greg Hudson wrote:
> >> It wasn't "const char *const *argv" before because a "char **"
> >> argument is not compatible with such a parameter, and C programs
> >> canonically take "char **argv", not "const char *const *argv". I'm
> >> not sure if it's even
>> It wasn't "const char *const *argv" before because a "char **"
>> argument is not compatible with such a parameter, and C programs
>> canonically take "char **argv", not "const char *const *argv". I'm
>> not sure if it's even valid C to silently change from char * to const
>> char * without an
> From: Greg Hudson [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 24, 2000 6:35 PM
>
> >> -char *const *argv;
> >> +char **argv;
>
> > Um. I don't think we can do this with argv. I'm surprised that it
> > isn't "const char * const * argv".
>
> We can do whatever we want with argv.
>> -char *const *argv;
>> +char **argv;
> Um. I don't think we can do this with argv. I'm surprised that it
> isn't "const char * const * argv".
We can do whatever we want with argv. That's pretty well-established.
It wasn't "const char *const *argv" before because a "char **"
argument
Greg Stein <[EMAIL PROTECTED]> writes:
> Presuming that it will be similar to Apache, then the log message only needs
> to describe the change. We don't require details of each function changed
> (since that can be seen in the change itself). In essence, the log messages
> describes the semantics o
Greg Stein wrote:
On Fri, Nov 24, 2000 at 06:46:25PM -0500, Greg Hudson wrote:
...
-char *const *argv;
+char **argv;
Um. I don't think we can do this with argv. I'm surprised that it isn't
"const char * const * argv".
Certainly, if we make a copy of the array (of pointers), then we could h
On Fri, Nov 24, 2000 at 03:59:07PM -0600, Karl Fogel wrote:
> Greg Hudson <[EMAIL PROTECTED]> writes:
> > Oh, right. Same standards as subversion, I take it? It's at the end
> > of this message.
>
> Not what I meant to imply -- actually, I don't know exactly what the
> APR standards are in that
Greg S, just coordinating:
Sounds like you're online and reviewing the changes already -- shall I
stay out of your way and assume you will do the commit soon? (It's
not that I'm worried about a conflict or something. It's just that I
will spend my time on other things than this change right now,
Looks good overall! I've got a few nits, below.
On Fri, Nov 24, 2000 at 06:46:25PM -0500, Greg Hudson wrote:
>...
> -char *const *argv;
> +char **argv;
Um. I don't think we can do this with argv. I'm surprised that it isn't
"const char * const * argv".
Certainly, if we make a copy of the
Greg Hudson <[EMAIL PROTECTED]> writes:
> Oh, right. Same standards as subversion, I take it? It's at the end
> of this message.
Not what I meant to imply -- actually, I don't know exactly what the
APR standards are in that regard. I was just asking for the log
message for my own sake, so it wo
> Could you write a log message to accompany the commit?
Oh, right. Same standards as subversion, I take it? It's at the end
of this message.
> There's also been talk about eliminating the redundant `opts' param
> to apr_getopt_long(). Did you not do that because you didn't want
> to mix two c
Greg Hudson <[EMAIL PROTECTED]> writes:
> Okay, here is my finalized patch for apr_getopt_long, to change over
> to the new simplified interface and to support interleaved arguments.
> Thanks, Greg, for clearing up how to do an anonymous checkout.
>
> I have asked rbb for commit access, but this b
Okay, here is my finalized patch for apr_getopt_long, to change over
to the new simplified interface and to support interleaved arguments.
Thanks, Greg, for clearing up how to do an anonymous checkout.
I have asked rbb for commit access, but this being Thanksgiving
weekend, I'm not sure if he'll b
25 matches
Mail list logo
