[Bug 215097] New: Example in getpwnam_r man page compares size_t variable to -1

[Bug 215097] New: Example in getpwnam_r man page compares size_t variable to -1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215097

            Bug ID: 215097
           Summary: Example in getpwnam_r man page compares size_t
                    variable to -1
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: low
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages@kernel-bugs.osdl.org
          Reporter: fabian@ritter-vogt.de
        Regression: No

The getpwnam_r man page
(https://man7.org/linux/man-pages/man3/getpwnam_r.3.html) has this in the
example code:

           size_t bufsize;
           ...

           bufsize = sysconf(_SC_GETPW_R_SIZE_MAX);
           if (bufsize == -1)          /* Value was indeterminate */
               bufsize = 16384;        /* Should be more than enough */

bufsize is a variable with unsigned type, so this results in:

mantest.c: In function 'main':
mantest.c:14:20: warning: comparison of integer expressions of different
signedness: 'size_t' {aka 'long unsigned int'} and 'int' [-Wsign-compare]
   14 |         if(bufsize == -1)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215097] Example in getpwnam_r man page compares size_t variable to -1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215097

Alejandro Colomar (man-pages) (alx.manpages@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alx.manpages@gmail.com

--- Comment #1 from Alejandro Colomar (man-pages) (alx.manpages@gmail.com) ---
Yes, long (sysconf(3) uses that) or ssize_t (to indicate a size) seem better
types.  Which one do you prefer?

Also I noticed that sysconf(3) doesn't document _SC_GETPW_R_SIZE_MAX.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215097] Example in getpwnam_r man page compares size_t variable to -1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215097

--- Comment #2 from Fabian (fabian@ritter-vogt.de) ---
(In reply to Alejandro Colomar (man-pages) from comment #1)
> Yes, long (sysconf(3) uses that) or ssize_t (to indicate a size) seem better
> types.  Which one do you prefer?

IMO using "long" makes the most sense. It's already used as the return value of
sysconf, while ssize_t has no direct relevance to the code.

> Also I noticed that sysconf(3) doesn't document _SC_GETPW_R_SIZE_MAX.

Oh, indeed!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 215097] Example in getpwnam_r man page compares size_t variable to -1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=215097

--- Comment #3 from Alejandro Colomar (man-pages) (alx.manpages@gmail.com) ---
Makes sense.  Fixed.
I'll keep the bug open until I fix sysconf(3) too.

Thanks!
Alex

    getpwnam.3: EXAMPLES: Fix signedness

    sysconf(3) returns a long.  Since it can return -1 (and we're
    making use of that value), we can't use size_t for bufsize.
    Use long.

    Link: <https://bugzilla.kernel.org/show_bug.cgi?id=215097>
    Reported-by: Fabian <fabian@ritter-vogt.de>
    Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>

diff --git a/man3/getpwnam.3 b/man3/getpwnam.3
index 71457a916..8ca13f1a2 100644
--- a/man3/getpwnam.3
+++ b/man3/getpwnam.3
@@ -304,7 +304,7 @@ main(int argc, char *argv[])
     struct passwd pwd;
     struct passwd *result;
     char *buf;
-    size_t bufsize;
+    long bufsize;
     int s;

     if (argc != 2) {

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.