[v4,1/2] system_data_types.7: Add 'void *'

  Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>

system_data_types.7: void *: Add info about generic function parameters and return value

Reported-by: Paul Eggert <eggert@cs.ucla.edu>
Reported-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>

system_data_types.7: void *: Add info about pointer artihmetic

Reported-by: Paul Eggert <eggert@cs.ucla.edu>
Reported-by: David Laight <David.Laight@ACULAB.COM>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>

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 <mtk.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <colomar.6.4.3@gmail.com>
---
 man7/system_data_types.7 | 80 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 78 insertions(+), 2 deletions(-)
  

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
  

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
  

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.
  

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