linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Alejandro Colomar <colomar.6.4.3@gmail.com>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	linux-man <linux-man@vger.kernel.org>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128
Date: Thu, 1 Oct 2020 12:46:30 +0100	[thread overview]
Message-ID: <CAH6eHdS0wJ9=Wx1Q7xS7AktZ_xKkAtdia7CjSQUmzabNRLwMDA@mail.gmail.com> (raw)
In-Reply-To: <193018da-3926-5cd5-c60d-78dadd08b4e0@gmail.com>

On Thu, 1 Oct 2020 at 12:24, Alejandro Colomar <colomar.6.4.3@gmail.com> wrote:
>
> Hi Jonathan,
>
> On 2020-10-01 12:50, Jonathan Wakely wrote:
> >> Ok,  I thought that GCC is part of the GNU project, but I don't know how
> >> much...
> >> I'll use "When using GCC," :)
> >
> > It is, but the GNU project is a large organisation, and has nothing to
> > say about non-standard types defined by GCC. Just because GCC is part
> > of a larger proejct, doesn't mean the entire project defines
> > something.
>
>
> Ok.
> >>   >>         Conforming to: GCC 4.6.0 and later.
> >>   >
> >>   > It doesn't conform to anything, shouldn't this say "This type is a GNU
> >>   > extension." or just "This type is an extension." ?
> >>
> >> That's what I had first: "Conforming to: GCC extension"
> >> Then I thought that I could include the version information,
> >> so I changed it to that.
> >>
> >> Maybe "GCC extension (since GCC 4.6.0)" would be better?
> >
> > I don't think that information belongs in the Conforming To section at
> > all. The version that added the type is nothing to do with
> > conformance, because it's an extension and there is nothing to conform
> > to.
> >
> > Look at 'man clock_gettime' for comparison. It has a VERSIONS section
> > and some individual constants are annotated with "(since Linux
> > 2.6.12)". That seems more appropriate for annotating individual types
> > within this man page which are not universally available.
> >
>
>
> Thank you!
>
> Updated:
>
> [[
> __int128
>        A signed integer type of a fixed width of exactly 128 bits.
>
>        When  using  GCC, it is supported only for targets which have an
>        integer mode wide enough to hold 128 bits.

I'm not sure "integer mode" is useful here. It's barely useful in the
GCC docs (it's an internal implementation detail of GCC, so not very
useful for end users). Outside the context of the GCC manual it's even
less likely to mean anything to users of this documentation.

Maybe just "supported only for targets where the compiler is able to
generate efficient code for 128-bit arithmetic" or something like
that. Maybe somebody else can suggest something better.


>
>        Versions: GCC 4.6.0 and later.
>
>        Conforming to: GCC extension.
>
>        Notes: This type is available without including any header.
>
>        Bugs: It is not possible to express an integer constant of  type
>        __int128  in  implementations  where  long long is less than 128
>        bits wide.
>
>        See also the intmax_t, intN_t and  unsigned  __int128  types  in
>        this page.
> ]]
>
> Just one more thing:
> Would you say "GCC extension" or "GNU extension"?

Good question. It's not specific to GCC, because other compilers also
define it, so maybe neither is appropriate.

Maybe openpty(3) is a suitable example to use, it says "CONFORMING TO
These are BSD functions, present in glibc. They are not standardized
in POSIX."

So maybe something like "This is a non-standard extension, present in
GCC. It is not standardized in C or POSIX." Again, maybe somebody else
has a better suggestion.

  reply	other threads:[~2020-10-01 11:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01  9:24 [RFC] man7/system_data_types.7: Document [unsigned] __int128 Alejandro Colomar
2020-10-01  9:57 ` Jonathan Wakely
2020-10-01 10:14   ` Alejandro Colomar
2020-10-01 10:50     ` Jonathan Wakely
2020-10-01 11:24       ` Alejandro Colomar
2020-10-01 11:46         ` Jonathan Wakely [this message]
2020-10-01 12:54     ` Szabolcs Nagy
2020-10-01 13:22       ` Alejandro Colomar
2020-10-01 13:46         ` Jonathan Wakely
2020-10-01 17:31     ` Joseph Myers
2020-10-02  8:10       ` 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='CAH6eHdS0wJ9=Wx1Q7xS7AktZ_xKkAtdia7CjSQUmzabNRLwMDA@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=gcc@gcc.gnu.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).