Hi Michael,
As you asked, I squashed.
And added the POSIX.1-2008 note too. Thanks for that!
Cheers,
Alex
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 | 80 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 79 insertions(+), 2 deletions(-)
create mode 100644 man3/void.3
--
2.28.0
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about generic function parameters and return value
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add Versions notes
Compatibility between function pointers and void * hasn't always been so.
Document when that was added to POSIX.
Reported-by: Michael Kerrisk <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
---
man7/system_data_types.7 | 80 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c82d3b388..277e05b12 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -679,7 +679,6 @@ See also the
.I uintptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- lconv ------------------------/
@@ -1780,7 +1779,6 @@ See also the
.I intptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- va_list ----------------------/
@@ -1814,6 +1812,84 @@ See also:
.BR va_copy (3),
.BR va_end (3)
.RE
+.\"------------------------------------- void * -----------------------/
+.TP
+.I void *
+.RS
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.
+.PP
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at all.
+Note that this feature prevents any kind of type checking:
+the programmer should be careful not to cast a
+.I void *
+value to a type incompatible to that of the underlying data,
+because that would result in undefined behavior.
+.PP
+This type is useful in function parameters and return value
+to allow passing values of any type.
+The function will usually use some mechanism to know
+of which type the underlying data passed to the function really is.
+.PP
+A value of this type can't be dereferenced,
+as it would give a value of type
+.I void
+which is not possible.
+Likewise, pointer arithmetic is not possible with this type.
+However, in GNU C, poitner arithmetic is allowed
+as an extension to the standard;
+this is done by treating the size of a
+.I void
+or of a function as 1.
+A consequence of this is that
+.I sizeof
+is also allowed on
+.I void
+and on function types, and returns 1.
+.PP
+The conversion specifier for
+.I void *
+for the
+.BR printf (3)
+and the
+.BR scanf (3)
+families of functions is
+.BR p ;
+resulting commonly in
+.B %p
+for printing
+.I void *
+values.
+.PP
+Versions:
+The POSIX requirement about compatibility between
+.I void *
+and function pointers was added in
+POSIX.1-2008 Technical Corrigendum 1 (2013).
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also:
+.BR malloc (3),
+.BR memcmp (3),
+.BR memcpy (3),
+.BR memset (3)
+.PP
+See also the
+.I intptr_t
+and
+.I uintptr_t
+types in this page.
+.RE
.\"--------------------------------------------------------------------/
.SH NOTES
The structures described in this manual page shall contain,
--
2.28.0
Signed-off-by: Alejandro Colomar <[email protected]>
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 000000000..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
On Fri, 2 Oct 2020 at 13:17, Alejandro Colomar <[email protected]> wrote:
>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: Add info about generic function parameters and return value
>
> Reported-by: Paul Eggert <[email protected]>
> Reported-by: David Laight <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: Add info about pointer artihmetic
>
> Reported-by: Paul Eggert <[email protected]>
> Reported-by: David Laight <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: Add Versions notes
>
> Compatibility between function pointers and void * hasn't always been so.
> Document when that was added to POSIX.
>
> Reported-by: Michael Kerrisk <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
> ---
> man7/system_data_types.7 | 80 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index c82d3b388..277e05b12 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -679,7 +679,6 @@ See also the
> .I uintptr_t
> and
> .I void *
> -.\" TODO: Document void *
> types in this page.
> .RE
> .\"------------------------------------- lconv ------------------------/
> @@ -1780,7 +1779,6 @@ See also the
> .I intptr_t
> and
> .I void *
> -.\" TODO: Document void *
> types in this page.
> .RE
> .\"------------------------------------- va_list ----------------------/
> @@ -1814,6 +1812,84 @@ See also:
> .BR va_copy (3),
> .BR va_end (3)
> .RE
> +.\"------------------------------------- void * -----------------------/
> +.TP
> +.I void *
> +.RS
> +According to the C language standard,
> +a pointer to any object type may be converted to a pointer to
> +.I void
> +and back.
> +POSIX further requires that any pointer,
> +including pointers to functions,
> +may be converted to a pointer to
> +.I void
> +and back.
> +.PP
> +Conversions from and to any other pointer type are done implicitly,
> +not requiring casts at all.
> +Note that this feature prevents any kind of type checking:
> +the programmer should be careful not to cast a
> +.I void *
> +value to a type incompatible to that of the underlying data,
> +because that would result in undefined behavior.
> +.PP
> +This type is useful in function parameters and return value
> +to allow passing values of any type.
> +The function will usually use some mechanism to know
> +of which type the underlying data passed to the function really is.
This sentence seems clunky.
How about "The function will typically use some mechanism to know the
real type of the data being passed via a pointer to void."
An example of "some mechanism" might be useful, though I don't have
one to offer.
> +.PP
> +A value of this type can't be dereferenced,
> +as it would give a value of type
> +.I void
> +which is not possible.
> +Likewise, pointer arithmetic is not possible with this type.
> +However, in GNU C, poitner arithmetic is allowed
Typo: pointer
> +as an extension to the standard;
> +this is done by treating the size of a
> +.I void
> +or of a function as 1.
> +A consequence of this is that
> +.I sizeof
> +is also allowed on
> +.I void
> +and on function types, and returns 1.
> +.PP
> +The conversion specifier for
> +.I void *
> +for the
> +.BR printf (3)
> +and the
> +.BR scanf (3)
> +families of functions is
> +.BR p ;
> +resulting commonly in
> +.B %p
> +for printing
> +.I void *
> +values.
What does "resulting commonly in %p for printing void * values" mean?
Is this just explaining that the format specifier p is commonly used
as "%p" (but sometimes as e.g. "%20p") ?
I'm not sure the "resulting commonly ..." part adds anything of value,
rather than just being confusing.
> +.PP
> +Versions:
> +The POSIX requirement about compatibility between
> +.I void *
> +and function pointers was added in
> +POSIX.1-2008 Technical Corrigendum 1 (2013).
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +See also:
> +.BR malloc (3),
> +.BR memcmp (3),
> +.BR memcpy (3),
> +.BR memset (3)
> +.PP
> +See also the
> +.I intptr_t
> +and
> +.I uintptr_t
> +types in this page.
> +.RE
> .\"--------------------------------------------------------------------/
> .SH NOTES
> The structures described in this manual page shall contain,
> --
> 2.28.0
>
> > +.I void *
> > +.RS
> > +According to the C language standard,
> > +a pointer to any object type may be converted to a pointer to
> > +.I void
> > +and back.
> > +POSIX further requires that any pointer,
> > +including pointers to functions,
> > +may be converted to a pointer to
> > +.I void
> > +and back.
> > +.PP
> > +Conversions from and to any other pointer type are done implicitly,
> > +not requiring casts at all.
> > +Note that this feature prevents any kind of type checking:
> > +the programmer should be careful not to cast a
> > +.I void *
> > +value to a type incompatible to that of the underlying data,
> > +because that would result in undefined behavior.
> > +.PP
> > +This type is useful in function parameters and return value
> > +to allow passing values of any type.
> > +The function will usually use some mechanism to know
> > +of which type the underlying data passed to the function really is.
>
> This sentence seems clunky.
>
> How about "The function will typically use some mechanism to know the
> real type of the data being passed via a pointer to void."
>
> An example of "some mechanism" might be useful, though I don't have
> one to offer.
It's also bollocks.
There are two main places 'void *' is used:
1) buffers (eg functions like read() and write()) when the
associated byte length is also passed.
This (sort of) includes memory allocation functions.
2) Passing a parameter for a callback function.
In this case the pointer is always cast back to
the original type before being used.
What it shouldn't be used for is structures you don't
want other code to look inside - use incomplete structs.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Hi Michael,
I'm sorry I forgot to increase the version count.
And given there are conversations continuing in old threads,
you may mix them easily. I'm a bit lost in the emails too.
I'll resend the latest patch (identically) as v4
(there's no v3, but this is the 4th time or so, so let's call it v4).
Regards,
Alex
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 | 80 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 79 insertions(+), 2 deletions(-)
create mode 100644 man3/void.3
--
2.28.0
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about generic function parameters and return value
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add Versions notes
Compatibility between function pointers and void * hasn't always been so.
Document when that was added to POSIX.
Reported-by: Michael Kerrisk <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
---
man7/system_data_types.7 | 80 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c82d3b388..277e05b12 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -679,7 +679,6 @@ See also the
.I uintptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- lconv ------------------------/
@@ -1780,7 +1779,6 @@ See also the
.I intptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- va_list ----------------------/
@@ -1814,6 +1812,84 @@ See also:
.BR va_copy (3),
.BR va_end (3)
.RE
+.\"------------------------------------- void * -----------------------/
+.TP
+.I void *
+.RS
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.
+.PP
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at all.
+Note that this feature prevents any kind of type checking:
+the programmer should be careful not to cast a
+.I void *
+value to a type incompatible to that of the underlying data,
+because that would result in undefined behavior.
+.PP
+This type is useful in function parameters and return value
+to allow passing values of any type.
+The function will usually use some mechanism to know
+of which type the underlying data passed to the function really is.
+.PP
+A value of this type can't be dereferenced,
+as it would give a value of type
+.I void
+which is not possible.
+Likewise, pointer arithmetic is not possible with this type.
+However, in GNU C, poitner arithmetic is allowed
+as an extension to the standard;
+this is done by treating the size of a
+.I void
+or of a function as 1.
+A consequence of this is that
+.I sizeof
+is also allowed on
+.I void
+and on function types, and returns 1.
+.PP
+The conversion specifier for
+.I void *
+for the
+.BR printf (3)
+and the
+.BR scanf (3)
+families of functions is
+.BR p ;
+resulting commonly in
+.B %p
+for printing
+.I void *
+values.
+.PP
+Versions:
+The POSIX requirement about compatibility between
+.I void *
+and function pointers was added in
+POSIX.1-2008 Technical Corrigendum 1 (2013).
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also:
+.BR malloc (3),
+.BR memcmp (3),
+.BR memcpy (3),
+.BR memset (3)
+.PP
+See also the
+.I intptr_t
+and
+.I uintptr_t
+types in this page.
+.RE
.\"--------------------------------------------------------------------/
.SH NOTES
The structures described in this manual page shall contain,
--
2.28.0
Signed-off-by: Alejandro Colomar <[email protected]>
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 000000000..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
On 10/2/20 8:14 AM, Alejandro Colomar wrote:
> +.I void *
GNU style is a space between "void" and "*", so this should be '.I "void\ *"',
both here and elsewhere. The backslash prevents a line break.
> +Conversions from and to any other pointer type are done implicitly,
> +not requiring casts at all.
> +Note that this feature prevents any kind of type checking:
> +the programmer should be careful not to cast a
Change "cast" to "convert", since the point is that no cast is needed.
> +.PP
> +The conversion specifier for
> +.I void *
> +for the
> +.BR printf (3)
> +and the
> +.BR scanf (3)
> +families of functions is
> +.BR p ;
> +resulting commonly in
> +.B %p
> +for printing
> +.I void *
> +values.
%p works with any object pointer type (or in POSIX, any pointer type), not just
void *.
Should also mention "void const *", "void volatile *", etc. Plus it really
should talk about plain "void", saying that it's a placeholder as a return value
for functions, for casting away values, and as a keyword in C11 for functions
with no parameters (though this is being changed in the next C version!). I sent
comments about most of this stuff already.
Hi Paul,
On 2020-10-02 18:53, Paul Eggert wrote:
> On 10/2/20 8:14 AM, Alejandro Colomar wrote:
>
>> +.I void *
>
> GNU style is a space between "void" and "*", so this should be '.I
> "void\ *"', both here and elsewhere. The backslash prevents a line break.
.I void *
renders with a space in between.
I'll show you the rendered version at the end of this email.
>
>> +Conversions from and to any other pointer type are done implicitly,
>> +not requiring casts at all.
>> +Note that this feature prevents any kind of type checking:
>> +the programmer should be careful not to cast a
>
> Change "cast" to "convert", since the point is that no cast is needed.
Ok.
>
>> +.PP
>> +The conversion specifier for
>> +.I void *
>> +for the
>> +.BR printf (3)
>> +and the
>> +.BR scanf (3)
>> +families of functions is
>> +.BR p ;
>> +resulting commonly in
>> +.B %p
>> +for printing
>> +.I void *
>> +values.
>
> %p works with any object pointer type (or in POSIX, any pointer type),
> not just void *.
In theory, no (if otherwise, I'd like to know why):
[[
p
The argument shall be a pointer to void. The value of the pointer
is converted to a sequence of printable characters, in an
implementation-defined manner.
]] POSIX.1-2008
However, it's unlikely to cause any problems, I must admit.
>
> Should also mention "void const *", "void volatile *", etc.
I already answered to this:
https://lore.kernel.org/linux-man/CAH6eHdQhh46TjVc72meWFTWCi7iouAod0iC1zLRga+c-36G+ig@mail.gmail.com/T/#m6f657e988558a556cb70f7c056ef7a24e73dbe4a
> Plus it
> really should talk about plain "void", saying that it's a placeholder as
> a return value for functions, for casting away values, and as a keyword
> in C11 for functions with no parameters (though this is being changed in
> the next C version!). I sent comments about most of this stuff already.
'void' is a completely different type from 'void *'.
This patch is for 'void *'.
If 'void' is documented,
it'll be in a different entry (although in the same page),
and therefore, that'll be for a different 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 cast a void * value to a type incompatible to that of
the underlying data, because that would result in undefined be-
havior.
This type is useful in function parameters and return value to
allow passing values of any type. The function will usually use
some mechanism to know of which type the underlying data passed
to the function really is.
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,
poitner 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; resulting commonly in %p
for printing void * values.
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.
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
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about generic function parameters and return value
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add info about pointer artihmetic
Reported-by: Paul Eggert <[email protected]>
Reported-by: David Laight <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: Add Versions notes
Compatibility between function pointers and void * hasn't always been so.
Document when that was added to POSIX.
Reported-by: Michael Kerrisk <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
system_data_types.7: void *: wfix
Reported-by: Jonathan Wakely <[email protected]>
Reported-by: Paul Eggert <[email protected]>
Signed-off-by: Alejandro Colomar <[email protected]>
---
man7/system_data_types.7 | 76 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index c82d3b388..7c1198802 100644
--- a/man7/system_data_types.7
+++ b/man7/system_data_types.7
@@ -679,7 +679,6 @@ See also the
.I uintptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- lconv ------------------------/
@@ -1780,7 +1779,6 @@ See also the
.I intptr_t
and
.I void *
-.\" TODO: Document void *
types in this page.
.RE
.\"------------------------------------- va_list ----------------------/
@@ -1814,6 +1812,80 @@ See also:
.BR va_copy (3),
.BR va_end (3)
.RE
+.\"------------------------------------- void * -----------------------/
+.TP
+.I void *
+.RS
+According to the C language standard,
+a pointer to any object type may be converted to a pointer to
+.I void
+and back.
+POSIX further requires that any pointer,
+including pointers to functions,
+may be converted to a pointer to
+.I void
+and back.
+.PP
+Conversions from and to any other pointer type are done implicitly,
+not requiring casts at all.
+Note that this feature prevents any kind of type checking:
+the programmer should be careful not to convert a
+.I void *
+value to a type incompatible to that of the underlying data,
+because that would result in undefined behavior.
+.PP
+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
+.IR void .
+.PP
+A value of this type can't be dereferenced,
+as it would give a value of type
+.IR 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
+.I void
+or of a function as 1.
+A consequence of this is that
+.I sizeof
+is also allowed on
+.I void
+and on function types, and returns 1.
+.PP
+The conversion specifier for
+.I void *
+for the
+.BR printf (3)
+and the
+.BR scanf (3)
+families of functions is
+.BR p .
+.PP
+Versions:
+The POSIX requirement about compatibility between
+.I void *
+and function pointers was added in
+POSIX.1-2008 Technical Corrigendum 1 (2013).
+.PP
+Conforming to:
+C99 and later; POSIX.1-2001 and later.
+.PP
+See also:
+.BR malloc (3),
+.BR memcmp (3),
+.BR memcpy (3),
+.BR memset (3)
+.PP
+See also the
+.I intptr_t
+and
+.I uintptr_t
+types in this page.
+.RE
.\"--------------------------------------------------------------------/
.SH NOTES
The structures described in this manual page shall contain,
--
2.28.0
Signed-off-by: Alejandro Colomar <[email protected]>
---
man3/void.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/void.3
diff --git a/man3/void.3 b/man3/void.3
new file mode 100644
index 000000000..db50c0f09
--- /dev/null
+++ b/man3/void.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
2.28.0
On 10/2/20 11:38 AM, Alejandro Colomar wrote:
> .I void *
>
> renders with a space in between.
That's odd, as "man(7)" says "All of the arguments will be printed next to each
other without intervening spaces". I'd play it safe and quote the arg anyway.
> > %p works with any object pointer type (or in POSIX, any pointer type),
> > not just void *.
> In theory, no (if otherwise, I'd like to know why):
Oh, you're right. I had missed that. In GNU/Linux hosts, though, any pointer
(including function pointers) can be given to %p.
The only platforms where %p wouldn't work on all pointers would be platforms
like IBM i, which has both 64-bit (process local) pointers and 128-bit (tagged
space) pointers and where you can declare and use pointers of different widths
in the same program.
Hi Paul,
On 2020-10-02 22:14, Paul Eggert wrote:
> On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>
>> .I void *
>>
>> renders with a space in between.
>
> That's odd, as "man(7)" says "All of the arguments will be printed next
> to each other without intervening spaces". I'd play it safe and quote
> the arg anyway.
Oops, that's a bug in man(7).
Don't worry about it.
Michael, you might want to have a look at it.
I'll also add Branden, who might have something to say about it.
>
>> > %p works with any object pointer type (or in POSIX, any pointer
type),
>> > not just void *.
>> In theory, no (if otherwise, I'd like to know why):
>
> Oh, you're right. I had missed that. In GNU/Linux hosts, though, any
> pointer (including function pointers) can be given to %p.
>
> The only platforms where %p wouldn't work on all pointers would be
> platforms like IBM i, which has both 64-bit (process local) pointers and
> 128-bit (tagged space) pointers and where you can declare and use
> pointers of different widths in the same program.
:-)
Cheers,
Alex
On 10/2/20 10:27 PM, Alejandro Colomar wrote:
> Hi Paul,
>
> On 2020-10-02 22:14, Paul Eggert wrote:
> > On 10/2/20 11:38 AM, Alejandro Colomar wrote:
> >
> >> .I void *
> >>
> >> renders with a space in between.
> >
> > That's odd, as "man(7)" says "All of the arguments will be printed next
> > to each other without intervening spaces". I'd play it safe and quote
> > the arg anyway.
>
> Oops, that's a bug in man(7).
> Don't worry about it.
I'm not sure where that text in man(7) comes from. However, for clarity
I would normally also use quotes in this case.
> Michael, you might want to have a look at it.
>
> I'll also add Branden, who might have something to say about it.
Yes, maybe Branden can add some insight.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
At 2020-10-03T09:10:14+0200, Michael Kerrisk (man-pages) wrote:
> On 10/2/20 10:27 PM, Alejandro Colomar wrote:
> > On 2020-10-02 22:14, Paul Eggert wrote:
> > > On 10/2/20 11:38 AM, Alejandro Colomar wrote:
> > >
> > >> .I void *
> > >>
> > >> renders with a space in between.
> > >
> > > That's odd, as "man(7)" says "All of the arguments will be
> > > printed next to each other without intervening spaces". I'd play
> > > it safe and quote the arg anyway.
> >
> > Oops, that's a bug in man(7). Don't worry about it.
>
> I'm not sure where that text in man(7) comes from. However, for
> clarity I would normally also use quotes in this case.
>
> > Michael, you might want to have a look at it.
> >
> > I'll also add Branden, who might have something to say about it.
>
> Yes, maybe Branden can add some insight.
The "short" answer[1] is that I think Alex is correct; Paul's caution is
unwarranted and arises from confusion with the font alternation macros
of the man(7) macro package. Examples of the latter are .BI and .BR.
Those set their even-numbered arguments in one font and odd-numbered
arguments in another, with no space between them. That suppression of
space is the reason they exist. With the "single-font" macros like .B
and .I[2], if you don't want space, don't type it.
I could say more, including an annotated explanation of the groff and
Version 7 Unix man(7) implementations of the I macro, if desired. :)
Regards,
Branden
[1] since as everyone knows, I struggle with brevity
[2] I (and others) discourage use of .SM and .SB because they can't be
distinguished from ordinary roman and bold type, respectively, on
terminals.
Hello Alex,
On 10/2/20 9:28 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar <[email protected]>
Patch applied.
Thanks,
Michael
> system_data_types.7: void *: Add info about generic function parameters and return value
>
> Reported-by: Paul Eggert <[email protected]>
> Reported-by: David Laight <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: Add info about pointer artihmetic
>
> Reported-by: Paul Eggert <[email protected]>
> Reported-by: David Laight <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: Add Versions notes
>
> Compatibility between function pointers and void * hasn't always been so.
> Document when that was added to POSIX.
>
> Reported-by: Michael Kerrisk <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
>
> system_data_types.7: void *: wfix
>
> Reported-by: Jonathan Wakely <[email protected]>
> Reported-by: Paul Eggert <[email protected]>
> Signed-off-by: Alejandro Colomar <[email protected]>
> ---
> man7/system_data_types.7 | 76 ++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
> index c82d3b388..7c1198802 100644
> --- a/man7/system_data_types.7
> +++ b/man7/system_data_types.7
> @@ -679,7 +679,6 @@ See also the
> .I uintptr_t
> and
> .I void *
> -.\" TODO: Document void *
> types in this page.
> .RE
> .\"------------------------------------- lconv ------------------------/
> @@ -1780,7 +1779,6 @@ See also the
> .I intptr_t
> and
> .I void *
> -.\" TODO: Document void *
> types in this page.
> .RE
> .\"------------------------------------- va_list ----------------------/
> @@ -1814,6 +1812,80 @@ See also:
> .BR va_copy (3),
> .BR va_end (3)
> .RE
> +.\"------------------------------------- void * -----------------------/
> +.TP
> +.I void *
> +.RS
> +According to the C language standard,
> +a pointer to any object type may be converted to a pointer to
> +.I void
> +and back.
> +POSIX further requires that any pointer,
> +including pointers to functions,
> +may be converted to a pointer to
> +.I void
> +and back.
> +.PP
> +Conversions from and to any other pointer type are done implicitly,
> +not requiring casts at all.
> +Note that this feature prevents any kind of type checking:
> +the programmer should be careful not to convert a
> +.I void *
> +value to a type incompatible to that of the underlying data,
> +because that would result in undefined behavior.
> +.PP
> +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
> +.IR void .
> +.PP
> +A value of this type can't be dereferenced,
> +as it would give a value of type
> +.IR 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
> +.I void
> +or of a function as 1.
> +A consequence of this is that
> +.I sizeof
> +is also allowed on
> +.I void
> +and on function types, and returns 1.
> +.PP
> +The conversion specifier for
> +.I void *
> +for the
> +.BR printf (3)
> +and the
> +.BR scanf (3)
> +families of functions is
> +.BR p .
> +.PP
> +Versions:
> +The POSIX requirement about compatibility between
> +.I void *
> +and function pointers was added in
> +POSIX.1-2008 Technical Corrigendum 1 (2013).
> +.PP
> +Conforming to:
> +C99 and later; POSIX.1-2001 and later.
> +.PP
> +See also:
> +.BR malloc (3),
> +.BR memcmp (3),
> +.BR memcpy (3),
> +.BR memset (3)
> +.PP
> +See also the
> +.I intptr_t
> +and
> +.I uintptr_t
> +types in this page.
> +.RE
> .\"--------------------------------------------------------------------/
> .SH NOTES
> The structures described in this manual page shall contain,
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hello Alex,
On 10/2/20 9:28 PM, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar <[email protected]>
Patch applied.
And, I think we're now at a sync point.
Thanks,
Michael
> ---
> man3/void.3 | 1 +
> 1 file changed, 1 insertion(+)
> create mode 100644 man3/void.3
>
> diff --git a/man3/void.3 b/man3/void.3
> new file mode 100644
> index 000000000..db50c0f09
> --- /dev/null
> +++ b/man3/void.3
> @@ -0,0 +1 @@
> +.so man7/system_data_types.7
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Hi Michael and Branden,
On 2020-10-03 09:48, G. Branden Robinson wrote:
> At 2020-10-03T09:10:14+0200, Michael Kerrisk (man-pages) wrote:
>> On 10/2/20 10:27 PM, Alejandro Colomar wrote:
>>> On 2020-10-02 22:14, Paul Eggert wrote:
>>> > On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>>> >
>>> >> .I void *
>>> >>
>>> >> renders with a space in between.
>>> >
>>> > That's odd, as "man(7)" says "All of the arguments will be
>>> > printed next to each other without intervening spaces". I'd play
>>> > it safe and quote the arg anyway.
>>>
>>> Oops, that's a bug in man(7). Don't worry about it.
>>
>> I'm not sure where that text in man(7) comes from. However, for
>> clarity I would normally also use quotes in this case.
Hi Michael and Branden,
Here is the offending line:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man7/man.7#n172
Thanks,
Alex
>>
>>> Michael, you might want to have a look at it.
>>>
>>> I'll also add Branden, who might have something to say about it.
>>
>> Yes, maybe Branden can add some insight.
>
> The "short" answer[1] is that I think Alex is correct; Paul's caution is
> unwarranted and arises from confusion with the font alternation macros
> of the man(7) macro package. Examples of the latter are .BI and .BR.
> Those set their even-numbered arguments in one font and odd-numbered
> arguments in another, with no space between them. That suppression of
> space is the reason they exist. With the "single-font" macros like .B
> and .I[2], if you don't want space, don't type it.
>
> I could say more, including an annotated explanation of the groff and
> Version 7 Unix man(7) implementations of the I macro, if desired. :)
>
> Regards,
> Branden
>
> [1] since as everyone knows, I struggle with brevity
> [2] I (and others) discourage use of .SM and .SB because they can't be
> distinguished from ordinary roman and bold type, respectively, on
> terminals.
>
On 10/3/20 9:48 AM, G. Branden Robinson wrote:
[...]
>> The "short" answer[1] is that I think Alex is correct; Paul's caution is
>> unwarranted and arises from confusion with the font alternation macros
>> of the man(7) macro package.? Examples of the latter are .BI and .BR.
>> Those set their even-numbered arguments in one font and odd-numbered
>> arguments in another, with no space between them.? That suppression of
>> space is the reason they exist.? With the "single-font" macros like .B
>> and .I[2], if you don't want space, don't type it.
Hi Branden,
This explanation is great :)
Would you mind writing a patch with it?
Cheers,
Alex
>>
>> I could say more, including an annotated explanation of the groff and
>> Version 7 Unix man(7) implementations of the I macro, if desired.? :)
:)
>>
>> Regards,
>> Branden
>>
>> [1] since as everyone knows, I struggle with brevity
>> [2] I (and others) discourage use of .SM and .SB because they can't be
>> distinguished from ordinary roman and bold type, respectively, on
>> terminals.
>>
On 10/3/20 9:48 AM, G. Branden Robinson wrote:
> At 2020-10-03T09:10:14+0200, Michael Kerrisk (man-pages) wrote:
>> On 10/2/20 10:27 PM, Alejandro Colomar wrote:
>>> On 2020-10-02 22:14, Paul Eggert wrote:
>>> > On 10/2/20 11:38 AM, Alejandro Colomar wrote:
>>> >
>>> >> .I void *
>>> >>
>>> >> renders with a space in between.
>>> >
>>> > That's odd, as "man(7)" says "All of the arguments will be
>>> > printed next to each other without intervening spaces". I'd play
>>> > it safe and quote the arg anyway.
>>>
>>> Oops, that's a bug in man(7). Don't worry about it.
>>
>> I'm not sure where that text in man(7) comes from. However, for
>> clarity I would normally also use quotes in this case.
>>
>>> Michael, you might want to have a look at it.
>>>
>>> I'll also add Branden, who might have something to say about it.
>>
>> Yes, maybe Branden can add some insight.
>
> The "short" answer[1] is that I think Alex is correct; Paul's caution is
> unwarranted and arises from confusion with the font alternation macros
> of the man(7) macro package. Examples of the latter are .BI and .BR.
> Those set their even-numbered arguments in one font and odd-numbered
> arguments in another, with no space between them. That suppression of
> space is the reason they exist. With the "single-font" macros like .B
> and .I[2], if you don't want space, don't type it.
>
> I could say more, including an annotated explanation of the groff and
> Version 7 Unix man(7) implementations of the I macro, if desired. :)
So, perhaps change:
All of the arguments will be printed next to each
other without intervening spaces, so that the .BR command
can be used to specify a word in bold followed by a mark of
punctuation in Roman.
to:
For the macros that produce alternating type faces,
the arguments will be printed next to each
other without intervening spaces, so that the .BR command
can be used to specify a word in bold followed by a mark of
punctuation in Roman.
?
> [1] since as everyone knows, I struggle with brevity
> [2] I (and others) discourage use of .SM and .SB because they can't be
> distinguished from ordinary roman and bold type, respectively, on
> terminals.
So, do you think it's worth discouraging this in man(7)?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/