From: Daniel Jacobowitz <drow@false.org>
To: Chet Ramey <chet.ramey@case.edu>
Cc: bug-readline@gnu.org, gdb@sourceware.org, chet@case.edu
Subject: Re: MinGW status for readline
Date: Wed, 12 Apr 2006 01:01:00 -0000 [thread overview]
Message-ID: <20060411151200.GA28268@nevyn.them.org> (raw)
In-Reply-To: <443BC59F.7040805@case.edu>
On Tue, Apr 11, 2006 at 11:05:03AM -0400, Chet Ramey wrote:
> Daniel Jacobowitz wrote:
> > On Tue, Apr 11, 2006 at 10:15:07AM -0400, Chet Ramey wrote:
> >> No, you never free username. isolate_tilde_prefix allocates memory
> >> whether you have the getpwent family available or not.
> >
> > It should be? user_entry = 0, so the other branch of the if is taken.
>
> ?
>
> `username' is assigned before user_entry is. It really should be freed
> outside the if-then block, now that I'm looking at it.
Well, yeah. But:
#if defined (HAVE_GETPWNAM)
user_entry = getpwnam (username);
#else
user_entry = 0;
#endif
if (user_entry == 0)
{
/* If the calling program has a special syntax for expanding tildes,
and we couldn't find a standard expansion, then let them try. */
if (tilde_expansion_failure_hook)
{
expansion = (*tilde_expansion_failure_hook) (username);
if (expansion)
{
dirname = glue_prefix_and_suffix (expansion, filename, user_len);
free (expansion);
}
}
free (username);
/* If we don't have a failure hook, or if the failure hook did not
expand the tilde, return a copy of what we were passed. */
if (dirname == 0)
dirname = savestring (filename);
}
#if defined (HAVE_GETPWENT)
else
{
free (username);
dirname = glue_prefix_and_suffix (user_entry->pw_dir, filename, user_len);
}
endpwent ();
#endif
Suppose !HAVE_GETPWENT. Then probably also !HAVE_GETPWNAM. So
user_entry = 0, so the first half of the if is taken, and username gets
freed.
I suppose this would make more sense though:
#if defined (HAVE_GETPWNAM)
else
{
free (username);
dirname = glue_prefix_and_suffix (user_entry->pw_dir, filename, user_len);
}
#endif
#if defined (HAVE_GETPWENT)
endpwent ();
#endif
>
> >> (I call endpwent() because its sole usual purpose is to close any open
> >> file descriptors on the password database, whatever it is. getpwent
> >> and getpwnam usually keep the database open.)
> >
> > Oh, huh. So much for useful man pages.
>
> The BSD man pages, at least, say
>
> The endpwent() function closes any open files.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ( ``Discere est Dolere'' -- chet )
> Live Strong. No day but today.
> Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/
>
--
Daniel Jacobowitz
CodeSourcery
prev parent reply other threads:[~2006-04-11 15:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-07 20:11 Daniel Jacobowitz
2006-04-07 21:53 ` Bob Rossi
2006-04-08 6:31 ` Daniel Jacobowitz
2006-04-11 14:15 ` Chet Ramey
2006-04-11 14:33 ` Daniel Jacobowitz
2006-04-11 14:40 ` Chet Ramey
2006-04-11 15:12 ` Daniel Jacobowitz
2006-04-11 15:31 ` Chet Ramey
2006-04-12 1:01 ` Daniel Jacobowitz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060411151200.GA28268@nevyn.them.org \
--to=drow@false.org \
--cc=bug-readline@gnu.org \
--cc=chet.ramey@case.edu \
--cc=chet@case.edu \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox