public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: mtk.manpages@gmail.com, linux-man@vger.kernel.org,
	gcc-patches@gcc.gnu.org, libc-alpha@sourceware.org,
	linux-kernel@vger.kernel.org, jwakely.gcc@gmail.com,
	David.Laight@ACULAB.COM
Subject: Re: [PATCH v4 1/2] system_data_types.7: Add 'void *'
Date: Fri, 2 Oct 2020 20:38:47 +0200	[thread overview]
Message-ID: <d794a058-0506-7c3c-6f3e-518a788933af@gmail.com> (raw)
In-Reply-To: <3941e130-df05-778b-dc76-90cd58400192@cs.ucla.edu>

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.

  reply	other threads:[~2020-10-02 18:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 12:16 [PATCH 0/2] Document " 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   ` [PATCH v5 " Alejandro Colomar
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 [this message]
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=d794a058-0506-7c3c-6f3e-518a788933af@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 read-only IMAP folder(s) and NNTP newsgroup(s).