Bug 11011 - utmpname(3) returns interger but man page says void
Summary: utmpname(3) returns interger but man page says void
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Michael Kerrisk
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-29 23:55 UTC by Halesh S
Modified: 2008-06-30 00:35 UTC (History)
0 users

See Also:
Kernel Version: 2.6.9-1.667
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Patch to fix the utmpname(3) man page. (1.23 KB, patch)
2008-06-29 23:59 UTC, Halesh S
Details | Diff

Description Halesh S 2008-06-29 23:55:53 UTC
In the link 
http://www.gnu.org/software/libtool/manual/libc/Manipulating-the-Database.html

It has mentioned that 
"The utmpname function returns a value of 0 if the new name was successfully 
stored, and a value of -1 to indicate an error. Note that utmpname does not try 
to open the database, and that therefore the return value does not say anything 
about whether the database can be successfully opened."

But in man page it says it return void in its prototype.

  void utmpname(const char *file);

In source code I have verified it returns int.

int
__utmpname (const char *file)
{
....
....
}

This is conflicting one and man page of utmpnae(3) needs to be fixed.
Comment 1 Halesh S 2008-06-29 23:59:38 UTC
Created attachment 16659 [details]
Patch to fix the utmpname(3) man page.
Comment 2 Michael Kerrisk 2008-06-30 00:21:26 UTC
Halesh, I'm not sure why you've created a bug report for this.  WANG Cong already forwarded me your observation of this problem, nd you were CCed on the mail that said it was fixed.
Comment 3 Halesh S 2008-06-30 00:26:33 UTC
Thanks Michael,

I havent got mail regarding the updates of this observation, hence i filed here.
Can you forward the mail, Which I was CCed from Wang.
Comment 4 Anonymous Emailer 2008-06-30 00:28:49 UTC
Reply-To: mtk.manpages@googlemail.com

On Mon, Jun 30, 2008 at 9:26 AM,  <bugme-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=11011
>
>
>
>
>
> ------- Comment #3 from halesh.s@gmail.com  2008-06-30 00:26 -------
> Thanks Michael,
>
> I havent got mail regarding the updates of this observation, hence i filed
> here.
> Can you forward the mail, Which I was CCed from Wang.




---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages@googlemail.com>
Date: Sun, Jun 29, 2008 at 4:53 AM
Subject: Re: [Patch] utmpname(3) returns int instead of void
To: WANG Cong <xiyou.wangcong@gmail.com>
Cc: Halesh S <halesh.s@gmail.com>, mtk.manpages@gmail.com,
linux-man@vger.kernel.org


On Sat, Jun 28, 2008 at 8:17 PM, WANG Cong <xiyou.wangcong@gmail.com> wrote:
>
> As pointed by Halesh S, utmpname(3) should return int, just like what it is
> in glibc's source code.
>
> Signed-off-by: WANG Cong <wangcong@zeuux.org>
> Cc: Halesh S <halesh.s@gmail.com>

Thnks!  Applied for man-pages-3.02.

Cheers,

Michael

> Index: man-pages-3.01/man3/getutent.3
> ===================================================================
> --- man-pages-3.01.orig/man3/getutent.3
> +++ man-pages-3.01/man3/getutent.3
> @@ -44,7 +44,7 @@ getutent, getutid, getutline, pututline,
>  .br
>  .B void endutent(void);
>  .sp
> -.BI "void utmpname(const char *" file );
> +.BI "int utmpname(const char *" file );
>  .SH DESCRIPTION
>  .BR utmpname ()
>  sets the name of the utmp-format file for the other utmp
> @@ -116,6 +116,10 @@ and
>  return a pointer to a \fIstruct utmp\fP on success, and NULL on failure.
>  This \fIstruct utmp\fP is allocated in static storage, and may be
>  overwritten by subsequent calls.
> +.br
> +.BR utmpname()
> +returns a value of 0 if the new name was successfully stored, and a
> +value of -1 to indicate an error.
>  .SH FILES
>  /var/run/utmp  database of currently logged-in users
>  .br
>
Comment 5 Halesh S 2008-06-30 00:35:28 UTC
Thanks a lot.

This mail was stored under a spam dir, which now I got by searching google mail box.
Sorry for re-filing the issue.

Note You need to log in before you can comment on or make changes to this bug.