Linux-man Archive on lore.kernel.org
 help / color / Atom feed
From: Alejandro Colomar <colomar.6.4.3@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Florian Weimer <fweimer@redhat.com>,
	Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org>,
	linux-man@vger.kernel.org, gcc-patches@gcc.gnu.org,
	mtk.manpages@gmail.com
Subject: Re: [PATCH 1/4] system_data_types.7: Add '__int128'
Date: Fri, 2 Oct 2020 21:01:33 +0200
Message-ID: <bcce5f89-6682-e089-d129-43c36fe3f392@gmail.com> (raw)
In-Reply-To: <f08ea5cf-d4ae-54aa-405b-829909156186@cs.ucla.edu>

Hi Paul,

On 2020-10-02 19:52, Paul Eggert wrote:
> Why describe __int128_t in these man pages at all? __int128_t is not a 
> property of either the kernel or of glibc, so it's out of scope.

Well, as I see it, [unsigned] __int128 is as good as [u]int64_t.
They are part of the C interface in Linux.
As a programmer I never cared if it was
Glibc providing me the type with a typedef,
or GCC providing me the type with its magic.

If you propose not to document the stdint types either,
I can see your position, but I'll disagree.



A few personal lines:

I just want to use it, and to do that,
I need a reference manual where to look for how to use it.
And belive me that unsigned __int128 has been very useful to me.

I think having this page with most of the types,
in a centralized manner, is exactly
what I would have needed in the past.
I have had trouble finding where ssize_t was defined.
I could have looked at the POSIX manual,
and I would have easily found that it is defined in <sys/types.h>,
but I didn't even know that it was a POSIX thing
(and I can tell that I'm not the only one who didn't know this :),
so I didn't even know where to search for it.

When I wanted to use unsigned __128, kind of the same thing,
where do you search for the documentation of something
that you don't even know who specified it?

When that happens, the first thing for me is to 'man something'.
If that doesn't give me any useful info, then duckduckgo something.

In the internet there's much info,
but also much of it is incomplete or incorrect,
so if I have the man, I trust the man over anything else
(except for the standard documents, of course).

But the standards documents usually provide the information
in a reverse fashion:
If you know where to look at, you'll find it.
But if you only know its name, it'll be hard to find where it is.

The man provides documentation with the name of what you want to
know about.  Simple and easy.

And man is faster than the internet :)


Regards,

Alex.

  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 16:34 [PATCH 0/4] Document 128-bit types Alejandro Colomar
2020-10-01 16:34 ` [PATCH 1/4] system_data_types.7: Add '__int128' Alejandro Colomar
2020-10-02 11:47   ` Florian Weimer
2020-10-02 17:52     ` Paul Eggert
2020-10-02 19:01       ` Alejandro Colomar [this message]
2020-10-02 19:54         ` Paul Eggert
2020-10-02 20:03           ` Alejandro Colomar
2020-10-02 20:19             ` Paul Eggert
2020-10-02 23:44               ` Alejandro Colomar
2020-10-02 23:53                 ` Paul Eggert
2020-10-05  7:12           ` Florian Weimer
2020-10-07  6:53             ` Michael Kerrisk (man-pages)
2020-10-07  6:57               ` Florian Weimer
2020-10-01 16:34 ` [PATCH 2/4] __int128.3: New link to system_data_types(7) Alejandro Colomar
2020-10-01 16:34 ` [PATCH 3/4] system_data_types.7: Add 'unsigned __int128' Alejandro Colomar
2020-10-01 16:34 ` [PATCH 4/4] unsigned-__int128.3: New link to system_data_types(7) Alejandro Colomar
2020-10-02 12:28 ` [PATCH v2 0/4] Document 128-bit types Alejandro Colomar
2020-10-02 12:28 ` [PATCH v2 1/4] system_data_types.7: Add '__int128' Alejandro Colomar
2020-10-02 12:28 ` [PATCH v2 2/4] __int128.3: New link to system_data_types(7) Alejandro Colomar
2020-10-02 12:28 ` [PATCH v2 3/4] system_data_types.7: Add 'unsigned __int128' Alejandro Colomar
2020-10-02 12:28 ` [PATCH v2 4/4] unsigned-__int128.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=bcce5f89-6682-e089-d129-43c36fe3f392@gmail.com \
    --to=colomar.6.4.3@gmail.com \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libc-alpha@sourceware.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

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git