Hi!

I've applied a patch to document the conformance of realloc(3) and
reallocarray(3).  See below, both the patch, and the formatted changes.

BTW, Paul, Bruno, does gnulib also wrap reallocarray(3)?  If not, it
should.


Have a lovely day!
Alex

---
        commit 7279622113349f32428fa14467ba2aa9ef090394
        Author: Alejandro Colomar <a...@kernel.org>
        Date:   Thu Jun 19 02:27:48 2025 +0200

            man/man3/malloc.3: VERSIONS, STANDARDS: Clarify conformance of 
realloc{,array}(3)
            
            Signed-off-by: Alejandro Colomar <a...@kernel.org>

        diff --git a/man/man3/malloc.3 b/man/man3/malloc.3
        index 9cdfa6b58..bd6cc161f 100644
        --- a/man/man3/malloc.3
        +++ b/man/man3/malloc.3
        @@ -241,6 +241,37 @@ .SH ATTRIBUTES
         .BR realloc ()
         T}     Thread safety   MT-Safe
         .TE
        +.SH VERSIONS
        +The behavior of
        +.I realloc(p,\~0)
        +in glibc doesn't conform to any of
        +C99,
        +C11,
        +POSIX.1-2001,
        +POSIX.1-2008,
        +POSIX.1-2017,
        +or POSIX.1-2024.
        +The C17 specification was changed to make it conforming,
        +but that specification was broken
        +\[em]it is impossible to write code that works portably\[em],
        +and C23 changed it again to make this undefined behavior,
        +acknowledging that the C17 specification was broad enough that
        +undefined behavior wasn't worse than that.
        +The POSIX.1-2024 specification is good,
        +and ideally the ISO C standard should embrace something similar,
        +but glibc does not conform to it.
        +.P
        +musl libc conforms to all versions of ISO C and POSIX.1.
        +.P
        +gnulib provides the
        +.I realloc-posix
        +module,
        +which provides a wrapper
        +.BR realloc ()
        +that conforms to POSIX.1-2024.
        +.P
        +.BR reallocarray ()
        +suffers the same issues in glibc.
         .SH STANDARDS
         .TP
         .BR malloc ()
        @@ -250,10 +281,10 @@ .SH STANDARDS
         .BR calloc ()
         .TQ
         .BR realloc ()
        -C11, POSIX.1-2008.
        +C23, POSIX.1-2024.
         .TP
         .BR reallocarray ()
        -None.
        +POSIX.1-2024.
         .SH HISTORY
         .TP
         .BR malloc ()

$ MANWIDTH=72 diffman-git HEAD
--- HEAD^:man/man3/malloc.3
+++ HEAD:man/man3/malloc.3
@@ -126,15 +126,34 @@
        │ realloc()                          │               │         │
        └────────────────────────────────────┴───────────────┴─────────┘
 
+VERSIONS
+       The behavior of realloc(p, 0) in glibc doesn’t conform to any of
+       C99, C11, POSIX.1‐2001, POSIX.1‐2008, POSIX.1‐2017, or
+       POSIX.1‐2024.  The C17 specification was changed to make it con‐
+       forming, but that specification was broken —it is impossible to
+       write code that works portably—, and C23 changed it again to
+       make this undefined behavior, acknowledging that the C17 speci‐
+       fication was broad enough that undefined behavior wasn’t worse
+       than that.  The POSIX.1‐2024 specification is good, and ideally
+       the ISO C standard should embrace something similar, but glibc
+       does not conform to it.
+
+       musl libc conforms to all versions of ISO C and POSIX.1.
+
+       gnulib provides the realloc‐posix module, which provides a wrap‐
+       per realloc() that conforms to POSIX.1‐2024.
+
+       reallocarray() suffers the same issues in glibc.
+
 STANDARDS
        malloc()
        free()
        calloc()
        realloc()
-              C11, POSIX.1‐2008.
+              C23, POSIX.1‐2024.
 
        reallocarray()
-              None.
+              POSIX.1‐2024.
 
 HISTORY
        malloc()


-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature

Reply via email to