map_uid_to_username() proposal

[Natanael Copa]

On Thu, 20 Apr 2006 17:18:08 -0400 (EDT)
"Robert P. J. Day" <rpjday at mindspring.com> wrote:

> On Fri, 21 Apr 2006, Natanael Copa wrote:
> 
> > On Thu, 20 Apr 2006 16:50:14 -0400 (EDT)
> > "Robert P. J. Day" <rpjday at mindspring.com> wrote:
> >
> > > hang on, let me clarify something here.  the reason that function is a
> > > little complicated is that it's designed to avoid any possible memory
> > > leak, no matter how many times it's called, so if you *want* that
> > > feature, you obviously have to pay for it with a little more size.
> >
> > What wrong with static buffers? (sure, you cannot use them with threads... but this is busybox)
> >
> > I like the:
> >
> > if (str = strcpy(func_that_returns_static_buf())) {
> >   /* use str */
> >   free(str);
> > }
> >
> > Its fast, its small, its convenient to use.
> 
> i'm confused.  where would this go relative to the whole
> map_uid_to_username() function?  how would returned results persist
> after that function returns?

Oh, that was what my previous code (where I mentally mixed getpwnam and getpwuid) was trying to show.

map_uid_username() is not a good example for showing static vars. I'd just return the pw->pw_uname, which persists after getpwuid returns. If that causes a memory leak, you have a bug in your getpwuid.

I'll use an itoa as example for static vars:

char *itoa(int n) {
	/* use static so the buffer presists after function returns */
	static char buf[24];
	strintf(buf, sizeof(buf), "%d", n);
	return (buf);
}

-- 
Natanael Copa