Hello Daniel,

Please find enclosed the next version of the patch.

There's a reference up from parsing data->set.userpwd to the place where
conn->bits.user_passwd is set.

I started having ideas about checking the range of the port number. If you
think I'm gold-plating, then feel free to remove or simplify the inner test.

It passes the automated tests, and seems to do the right thing in informal use.

You probably don't want to check in the "use warnings" in runtests.pl,
because I haven't fixed all the warnings.

You probably don't want to check in the "/opt/perl5/bin/perl" in
memanalyze.pl. I don't understand what /usr/bin/env does, but
"#!/usr/bin/env perl" also seems to work in memanalyze.pl. Should it be
the standard way curl invokes interpreters?

Regards,
James Cone.

At 16:17 17/05/2002 +0200, Daniel Stenberg wrote:
>On Fri, 17 May 2002, J. Cone wrote:
>
> > I'm not sure that my mailer does quoting correctly, so I have divided your
> > replies into sections and reply to them here.
>
>I'm sure we'll understand each other!
>
> > AAA && CCC:
> >
> > I think I don't understand what conn->bits.user_passwd being true means.
> > I have been assuming it means only that data->state.user and
> > data->state.passwd are defined.
>
>I wouldn't say that is a correct description. The user and passwd always get
>the default user and passwd filled-in, and they will be used by the ftp when
>connecting "anonymously".
>
>The conn->bits.user_passwd is set and means "we have a user+password config
>set that we should use". For ftp, that basicly makes no difference as it'll
>always use the name and password for all connections, but for HTTP this means
>that it'll include the name and password, which it doesn't usually do. (FTP
>and HTTP being examples here, the concept should apply on all supported
>protocols.)
>
> > Please explain how it can be that:
> > we are doing FTP or HTTP
> > and
> > data->state.user and data->state.passwd are defined
> > and
> > conn->bits.user_passwd is false?
>
>Because the user_passwd is only true in non-default cases. Just as you
>concluded.
>
> > I think I have introduced a bug we haven't discovered yet; if all of the
> > outputs were set in the section at line 1865, then the section at line 1948
> > that interprets data->set.userpwd should be setting conn->bits.user_passwd
> > and isn't. I've changed the test at line 1314 back, to minimise code
> > change. If you think interpreting data->set.userpwd once only is a good
> > idea, then I could assign it false at line 1314, as I initially wanted, and
> > true at about line 1948, when I discover that data->set.userpwd is set and
> > use the contents.
>
>It is enough to do it once. The data->set.userpwd value is set by a
>curl_easy_setopt() invokation, and it won't change during this function's
>"lifetime". That's why the comment refers the copying of that data as
>"inheriting".
>
> > There is a _NETRC_DEBUG that causes netrc.c to make a main(). This is not
> > controlled by --enable-debug in the configure script. It's different from
> > the DEVELDEBUG that you're considering, isn't it?
>
>Yes it is. I'm talking about changing the MALLOCDEBUG to DEVELDEBUG so that
>it becomes more suitably named for general development debug stuff, like the
>malloc and the netrc "hacks".
>
> > Please can renaming MALLOC_DEBUG be a separate patch, to keep down the
> > number of changed files in my patch?
>
>Oh most certainly, you just use that MALLOCDEBUG option and I can do the
>renaming afterwards. I was just blabbing about. ;-)
>
> > When you say that there is only one colon in the URL, I disagree. I have
> > moved the code that extracts the username and password further down the
> > file, so that it won't be confused by colons in port numbers or IPV6
> > addresses. That means that here, there could be colons from:
> > - username:password
> > - IPv6 address
> > - port number
>
>Aaaaaah. That's the part I missed, the moving. Ok, now it makes more sense.
>Sorry, just a case of me not reading properly.
>
> > If you consider the whole of the change, up to the block comment, it saves
> > nine non-blank lines, and makes IPv6 addresses not need a special case
> > (although I admit to not having tested them - is there someone who could
> > with relatively small grief?).
>
>I can test that. I have IPv6 running on my localhost.
>
> > We could get the same effect as strspn (testing that everything after the
> > colon is digits, so we can protect ourselves against a false colon earlier
> > in the string) by using strtoul, if you prefer that over strspn.
>
>Yes, I would very much prefer strtoul().
>
> > I *really* don't want to add a special case to the IPv4 case, for finding
> > the possible "@" and then the possible colon and then blindly doing atoi on
> > something I haven't tested is a digit string. Am I making sense here?
>
>You're making perfect sense. I was wrong.
>
>Thanks for your clarifications. I am now a wiser person! ;-)
>
>--
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/

_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/