[PATCH v2 2/4] Document malloc alignment

[DJ Delorie]

Paul Eggert <eggert@cs.ucla.edu> writes:
>  
> +@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)}.

Suggest "In some implementations other than..." as they're not all like
the above.

Suggest an example, like "For example, malloc(4) might only be aligned
to a 4-byte boundary, rather than an 8 or 16 byte alignment."
Substitute appropriate sizeof/alignof if desired.

Do we want to include advice to programmers here?  Such as "Programmers
must not assume alignment larger than the allocation size, and should
use aligned_alloc() et al if needed."

> +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.
>  @end deftypefun

Agreed with Florian, this still needs to note that reallocing an
aligned_alloc chunk may return a chunk of lesser alignment.

> @@ -980,6 +990,12 @@ is declared in @file{stdlib.h}.
> +In @theglibc{}, the vector is aligned the same way that @code{malloc}
> +aligns its returned values.  In other implementations, it is merely
> +aligned suitably for any array of fundamentally-aligned elements each
> +with size at most @code{max (@var{size}, 1)}.
> +

s/it is/it may be/