[PATCH v2 3/4] Say malloc (0) != NULL is now common; resection

DJ Delorie dj@redhat.com
Wed Feb 11 22:37:13 GMT 2026


Paul Eggert <eggert@cs.ucla.edu> writes:
>  @itemize @bullet
>  @item
> -In @theglibc{}, a successful @code{malloc (0)}
> -returns a non-null pointer to a newly allocated size-zero block;
> -other implementations may return @code{NULL} instead.
> -POSIX and the ISO C standard allow both behaviors.
> -
> -@item
> -In implementations other than @theglibc{}, a non-null pointer returned
> -by @code{malloc (@var{size})} is guaranteed to be aligned only for
> -fundamentally-aligned objects of size at most @code{max (@var{size}, 1)}.

> +In @theglibc{} and most other systems, a successful @code{malloc (0)}
> +returns a non-null pointer to a newly allocated size-zero block.
> +However, in IBM AIX a successful @code{malloc (0)} returns a null pointer,
> +and this breaks common code such as the implementation of @code{xmalloc}
> +given in this manual (@pxref{Malloc Examples}).

Do we need to mention AIX by name?  Can't we just say ", in some
implementations, malloc(0) may return a null pointer."

We should add a note about how to be portable (that's the purpose of
this section, yes? ;) like "Thus, portable programs should never pass a
size of zero to allocation functions."

> +@item
> +In other implementations, a non-null pointer returned

"In some non-GNU implementations,"

> @@ -876,6 +919,8 @@ is left undisturbed.
>  Any non-null pointer returned by @code{realloc} satisfies the same
>  alignment restrictions as a similar pointer returned by @code{malloc}
>  with the same size.
> +Any special alignment created by @code{aligned_alloc}
> +and similar functions is lost after @code{realloc}.

Ah, here it is ;-)

> +In @theglibc{}, the vector is aligned the same way that @code{malloc}
> +aligns its returned values.  In other implementations, it is merely

s/it is/it may be/

> @@ -1927,7 +1973,9 @@ functions (that is, all the functions used by the application,
>  failures, and, at run time, to heap corruption and application crashes.
>  Replacement functions should implement the behavior documented for
>  their counterparts in @theglibc{}; for example, the replacement
> -@code{free} should also preserve @code{errno}.
> +@code{malloc} should return a null pointer only when failing
> +and should return pointers aligned to @code{alignof (max_align_t)},
> +and the replacement @code{free} should preserve @code{errno}.

Too many "and"'s.  Replace the first with a comma?  Or with ", it" ?



More information about the Libc-alpha mailing list