]> git.ipfire.org Git - thirdparty/man-pages.git/commit
Various pages: SYNOPSIS: Use VLA syntax in function parameters
authorAlejandro Colomar <alx.manpages@gmail.com>
Fri, 26 Aug 2022 20:48:26 +0000 (22:48 +0200)
committerAlejandro Colomar <alx@kernel.org>
Wed, 9 Nov 2022 23:44:59 +0000 (00:44 +0100)
commit1eed67e75deff662dffce3195e55e608809eaafd
treec17d52fa109792e24b551c519856d68a0fe67b28
parent6bb53a30af9960b30ca58bb62002da926f853c81
Various pages: SYNOPSIS: Use VLA syntax in function parameters

The WG14 charter for C23 added one principle to the ones in
previous standards:

[
15.  Application Programming Interfaces (APIs) should be
self-documenting when possible.  In particular, the order of
parameters in function declarations should be arranged such that
the size of an array appears before the array.  The purpose is to
allow Variable-Length Array (VLA) notation to be used. This not
only makes the code's purpose clearer to human readers, but also
makes static analysis easier.  Any new APIs added to the Standard
should take this into consideration.
]

ISO C doesn't allow using VLA syntax when the parameter used for
the size of the array is declared _after_ the parameter that is a
VLa.  That's a minor issue that could be easily changed in the
language without backwards-compatibility issues, and in fact it
seems to have been proposed, and not yet discarded, even if it's
not going to change in C23.

Since the manual pages SYNOPSIS are not bounded by strict C legal
syntax, but we already use some "tricks" to try to convey the most
information to the reader even if it might not be the most legal
syntax, we can also make a small compromise in this case, using
illegal syntax (at least not yet legalized) to add important
information to the function prototypes.

If we're lucky, compiler authors, and maybe even WG14 members, may
be satisfied by the syntax used in these manual pages, and may
decide to implement this feature to the language.

It seems to me a sound syntax that isn't ambiguous, even if it
deviates from the common pattern in C that declarations _always_
come before use.  But it's a reasonable tradeoff.

This change will make the contract between the programmer and the
implementation clearer just by reading a prototype.  For example,

  size_t strlcpy(char *restrict dst, const char *restrict src,
                 size_t size);

    vs

  size_t strlcpy(char dst[restrict .size], const char *restrict src,
                 size_t size);

the second prototype above makes it clear that the 'dst' buffer
will be safe from overflow, but the 'src' one clearly needs to be
NUL-terminated, or it might cause UB, since nothing tells the
function how long it is.

Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2611.htm>
Cc: Ingo Schwarze <schwarze@openbsd.org>
Cc: JeanHeyd Meneide <wg14@soasis.org>
Cc: Martin Uecker <uecker@tugraz.at>
Cc: <gcc@gcc.gnu.org>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
72 files changed:
man3/confstr.3
man3/des_crypt.3
man3/fgetc.3
man3/fgetws.3
man3/getcwd.3
man3/getdirentries.3
man3/getgrent_r.3
man3/getgrnam.3
man3/gethostbyname.3
man3/getlogin.3
man3/getmntent.3
man3/getnameinfo.3
man3/getnetent_r.3
man3/getprotoent_r.3
man3/getpwent_r.3
man3/getpwnam.3
man3/getrpcent_r.3
man3/getservent_r.3
man3/getspnam.3
man3/inet_net_pton.3
man3/inet_ntop.3
man3/mblen.3
man3/mbrlen.3
man3/mbrtowc.3
man3/mbsnrtowcs.3
man3/mbsrtowcs.3
man3/mbstowcs.3
man3/mbtowc.3
man3/mempcpy.3
man3/mq_receive.3
man3/mq_send.3
man3/printf.3
man3/pthread_setname_np.3
man3/ptsname.3
man3/random.3
man3/random_r.3
man3/regex.3
man3/resolver.3
man3/rpc.3
man3/setaliasent.3
man3/setbuf.3
man3/setnetgrent.3
man3/stpncpy.3
man3/strcasecmp.3
man3/strcat.3
man3/strcmp.3
man3/strcpy.3
man3/strdup.3
man3/strerror.3
man3/strfmon.3
man3/strfromd.3
man3/strftime.3
man3/string.3
man3/strnlen.3
man3/strxfrm.3
man3/ttyname.3
man3/unlocked_stdio.3
man3/wcpncpy.3
man3/wcsncasecmp.3
man3/wcsncat.3
man3/wcsncmp.3
man3/wcsncpy.3
man3/wcsnlen.3
man3/wcsnrtombs.3
man3/wcsrtombs.3
man3/wcstombs.3
man3/wmemchr.3
man3/wmemcmp.3
man3/wmemcpy.3
man3/wmemmove.3
man3/wmemset.3
man3/wprintf.3