Hi, Here's a revision of this change, addressing some concerns. I'm only showing the formatted changes, since the patch itself is unimportant.
Have a lovely day!
Alex
---
$ MANWIDTH=72 diffman-git HEAD
--- HEAD^:man/man3/malloc.3
+++ HEAD:man/man3/malloc.3
@@ -126,15 +126,32 @@
│ 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.
+
+ 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()
@@ -214,6 +231,22 @@
POSIX and the C standard do not allow replacement of malloc(),
free(), calloc(), and realloc().
+BUGS
+ Programmers would naturally expect that realloc(p, size) is con‐
+ sistent with free(p) and malloc(size). This is not explicitly
+ required by POSIX.1‐2024 or C11, but all conforming implementa‐
+ tions are consistent with that.
+
+ The glibc implementation of realloc() is not consistent with
+ that, and as a consequence, it is dangerous to call
+ realloc(p, 0) in glibc.
+
+ A trivial workaround for glibc is calling it as
+ realloc(p, size?size:1).
+
+ The workaround for reallocarray() in glibc —which shares the
+ same bug— would be reallocarray(p, n?n:1, size?size:1).
+
EXAMPLES
#include <err.h>
#include <stddef.h>
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
