All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Jan Engelhardt <jengelh@inai.de>
Cc: linux-man@vger.kernel.org
Subject: Re: [PATCH] man/man3/getnameinfo.3: Mention behavior for AF_UNIX
Date: Tue, 20 Oct 2026 16:27:14 +0200	[thread overview]
Message-ID: <atd04IuG4GBl6PxM@debian> (raw)
In-Reply-To: <20261020115143.75371-1-jengelh@inai.de>

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

Hi Jan,

> Date: 2026-10-20 13:51:43+0200
> From: Jan Engelhardt <jengelh@inai.de>
>
> Signed-off-by: Jan Engelhardt <jengelh@inai.de>
> ---
>  man/man3/getnameinfo.3 | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/man/man3/getnameinfo.3 b/man/man3/getnameinfo.3
> index 7db812948..6c2a08275 100644
> --- a/man/man3/getnameinfo.3
> +++ b/man/man3/getnameinfo.3
> @@ -121,6 +121,14 @@ cannot be determined.)
>  If set, then the numeric form of the service address is returned.
>  (When not set, this will still happen in case the service's name
>  cannot be determined.)
> +.P
> +Behavior for passing other sockaddr types to getnameinfo is unspecified by

This 'other' seems out of context.  I don't see a recent earlier mention
that the address family of the socket should be AF_INET/6.  There's one
at the top, but that seems far enough that a reader might get confused.

Perhaps we could have this text in a VERSIONS section, and instead of
assuming the reader remembers, we could be explicit about it.

> +POSIX.
> +Portable programs should not expect any particular behavior.
> +For e.g. AF_UNIX/sockaddr_un,
> +many libc implementations fail such a call,
> +some succeed but provide zero-length strings in \fIhost\fP and \fIserv\fP,
> +and some fill these buffers with pseudo values.

I'd rewrite a little bit:

	.SH VERSIONS
	POSIX only specifies the behavior for sockets of the
	.B AF_INET
	and
	.B AF_INET6
	address families.
	Other address families are non-portable;
	for example, for
	.BR AF_UNIX ,
	many libc implementations fail,
	some succeed but provide zero-length strings in
	.I host
	and
	.IR serv ,
	and some fill these buffers with pseudo-values.

BTW, out of curiosity, what do those pseudo-values look like?


Have a lovely day!
Alex

>  .SS Extensions to getnameinfo() for Internationalized Domain Names
>  Starting with glibc 2.3.4,
>  .BR getnameinfo ()
> -- 
> 2.56.0
> 
> 

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-10-20 14:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 11:51 [PATCH] man/man3/getnameinfo.3: Mention behavior for AF_UNIX Jan Engelhardt
2026-10-20 14:27 ` Alejandro Colomar [this message]
2026-10-20 16:01   ` Jan Engelhardt
2026-10-21 18:01     ` 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=atd04IuG4GBl6PxM@debian \
    --to=alx@kernel.org \
    --cc=jengelh@inai.de \
    --cc=linux-man@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.