From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: mtk.manpages@gmail.com
Cc: Alejandro Colomar <colomar.6.4.3@gmail.com>,
linux-man@vger.kernel.org, gcc-patches@gcc.gnu.org,
libc-alpha@sourceware.org, eggert@cs.ucla.edu,
linux-kernel@vger.kernel.org, jwakely.gcc@gmail.com,
David.Laight@ACULAB.COM
Subject: [PATCH v5 0/2] Document 'void *'
Date: Fri, 2 Oct 2020 21:28:13 +0200 [thread overview]
Message-ID: <20201002192814.14113-1-colomar.6.4.3@gmail.com> (raw)
In-Reply-To: <20201002151419.32053-1-colomar.6.4.3@gmail.com>
Hi Michael,
Here I added a wfix fixing some wording issues and a few typos
spotted by Paul and Jonathan in the (many) threads.
As previously, it is squashed into a single commit.
Thanks again for those who reviewed the patch!
BTW, for those who don't have a local repo of the man-pages,
below you can see a rendered version of the patch.
Thanks,
Alex
[[
void *
According to the C language standard, a pointer to any object
type may be converted to a pointer to void and back. POSIX fur-
ther requires that any pointer, including pointers to functions,
may be converted to a pointer to void and back.
Conversions from and to any other pointer type are done implic-
itly, not requiring casts at all. Note that this feature pre-
vents any kind of type checking: the programmer should be care-
ful not to convert a void * value to a type incompatible to that
of the underlying data, because that would result in undefined
behavior.
This type is useful in function parameters and return value to
allow passing values of any type. The function will typically
use some mechanism to know the real type of the data being
passed via a pointer to void.
A value of this type can't be dereferenced, as it would give a
value of type void, which is not possible. Likewise, pointer
arithmetic is not possible with this type. However, in GNU C,
pointer arithmetic is allowed as an extension to the standard;
this is done by treating the size of a void or of a function as
1. A consequence of this is that sizeof is also allowed on void
and on function types, and returns 1.
The conversion specifier for void * for the printf(3) and the
scanf(3) families of functions is p.
Versions: The POSIX requirement about compatibility between void
* and function pointers was added in POSIX.1-2008 Technical Cor-
rigendum 1 (2013).
Conforming to: C99 and later; POSIX.1-2001 and later.
See also: malloc(3), memcmp(3), memcpy(3), memset(3)
See also the intptr_t and uintptr_t types in this page.
]]
Alejandro Colomar (2):
system_data_types.7: Add 'void *'
void.3: New link to system_data_types(7)
man3/void.3 | 1 +
man7/system_data_types.7 | 76 ++++++++++++++++++++++++++++++++++++++--
2 files changed, 75 insertions(+), 2 deletions(-)
create mode 100644 man3/void.3
--
2.28.0
next prev parent reply other threads:[~2020-10-02 19:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 12:16 [PATCH 0/2] Document 'void *' Alejandro Colomar
2020-10-02 12:16 ` [PATCH 1/2] system_data_types.7: Add " Alejandro Colomar
2020-10-02 13:15 ` Jonathan Wakely
2020-10-02 13:26 ` David Laight
2020-10-02 12:16 ` [PATCH 2/2] void.3: New link to system_data_types(7) Alejandro Colomar
2020-10-02 15:14 ` [PATCH v4 0/2] Document 'void *' Alejandro Colomar
2020-10-02 19:28 ` Alejandro Colomar [this message]
2020-10-02 19:28 ` [PATCH v5 1/2] system_data_types.7: Add " Alejandro Colomar
2020-10-03 8:01 ` Michael Kerrisk (man-pages)
2020-10-02 19:28 ` [PATCH v5 2/2] void.3: New link to system_data_types(7) Alejandro Colomar
2020-10-03 8:01 ` Michael Kerrisk (man-pages)
2020-10-02 15:14 ` [PATCH v4 1/2] system_data_types.7: Add 'void *' Alejandro Colomar
2020-10-02 16:53 ` Paul Eggert
2020-10-02 18:38 ` Alejandro Colomar
2020-10-02 20:14 ` Paul Eggert
2020-10-02 20:27 ` Alejandro Colomar
2020-10-03 7:10 ` Michael Kerrisk (man-pages)
2020-10-03 7:48 ` G. Branden Robinson
2020-10-03 8:55 ` Alejandro Colomar
2020-10-03 11:47 ` Alejandro Colomar
2020-10-03 11:52 ` Michael Kerrisk (man-pages)
2020-10-02 15:14 ` [PATCH v4 2/2] void.3: New link to system_data_types(7) Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201002192814.14113-1-colomar.6.4.3@gmail.com \
--to=colomar.6.4.3@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=eggert@cs.ucla.edu \
--cc=gcc-patches@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).