All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>
Subject: Re: ptrace.2: Simplify signature? s/enum \w*/int/
Date: Tue, 9 Feb 2021 23:34:33 +0100	[thread overview]
Message-ID: <e5de8f47-b8cc-ee52-4702-5bdf7193f0d8@gmail.com> (raw)
In-Reply-To: <eb01e43f-6ab4-c4c9-62b5-a705aab906ae@gmail.com>

Hi Michael,

On 2/9/21 7:25 PM, Michael Kerrisk (man-pages) wrote:
> Hi Alex,
> 
> On 2/8/21 11:36 PM, Alejandro Colomar (man-pages) wrote:
>> [CC += linux-man@]
>>
>> I forgot the list.
>>
>> On 2/8/21 11:34 PM, Alejandro Colomar (man-pages) wrote:
>>> Hi Michael,
>>>
>>> I think we should simplify the prototype of ptrace(2) from using 'enum
>>> __ptrace_request' to 'int'.  It is an implementation detail that should
>>> be transparent to the user.  Other pages where glibc uses an 'enum' are
>>> documented to use 'int' (I don't remember the names of those, but
>>> remember having seen them a few days ago.  Otherwise, we might have to
>>> document 'enum' elsewhere, which I don't think adds any value.  What do
>>> you think about it?
> 
> I'm somewhat conservative on this point. It's been documented
> this way forever, so I'm inclined to pause before changing it.
Okay.

> I feel like we lack information. I'd like to know about some of
> the other cases where enums in glibc are documented instead as int.
> But, on the other hand, maybe this is not the highest priority,
> so it may not be worth too much effort to discover those examples.

I checked all of them ;)
It's more like 50/50.

Here are the glibc results (grepping though the kernel is taking much
longer, but I guess the command will have ended by tomorrow morning, and
I'll send you a follow-up.


.../gnu/glibc$ man_lsfunc ../../linux/man-pages/man2 \
               |while read -r f; do \
                       grep_glibc_prototype $f;
               done \
               |grep enum;
extern long pciconfig_iobase(enum __pciconfig_iobase_which __which,
extern int prlimit (__pid_t __pid, enum __rlimit_resource __resource,
extern int prlimit (__pid_t __pid, enum __rlimit_resource __resource,
extern int prlimit (__pid_t __pid, enum __rlimit_resource __resource,
extern int prlimit (__pid_t __pid, enum __rlimit_resource __resource,
extern int ptrace (enum __ptrace_request __request, ...);
extern long int ptrace (enum __ptrace_request __request, ...) __THROW;
.../gnu/glibc$


Of the above, only ptrace(2) uses 'enum' in the manual page.
The others use 'int'.


.../gnu/glibc$ man_lsfunc ../../linux/man-pages/man3 \
               |while read -r f; do \
                       grep_glibc_prototype $f;
               done \
               |grep enum;
extern int mcheck (void (*__abortfunc)(enum mcheck_status)) __THROW;
extern int mcheck_pedantic (void (*__abortfunc)(enum mcheck_status))
__THROW;
extern enum mcheck_status mprobe (void *__ptr) __THROW;
.../gnu/glibc$

All of the above use 'enum' in the manual page.

Cheers,

Alex

......

man_lsfunc prints a list of all C functions documented in the SYNOPSIS
of a directory such as man2 (it can also be used on a single manual
page, such as `man_lsfunc man2/open.2`).

function man_lsfunc()
{
	if ! [ -v 1 ]; then
		>&2 echo "Usage: ${FUNCNAME[0]} <dir>";
		return ${EX_USAGE};
	fi

	find "${1}" -type f \
	|xargs grep -l "\.SH SYNOPSIS" \
	|sort -V \
	|while read -r manpage; do
		<${manpage} \
		sed -n \
			-e '/^\.TH/,/^\.SH/{/^\.SH/!p}' \
			-e "/^\.SH SYNOPSIS/p" \
			-e "/^\.SH SYNOPSIS/,/^\.SH/{/^\.SH/!p}" \
		|sed \
			-e '/Feature/,$d' \
			-e '/:/,$d' \
		|man -P cat -l - 2>/dev/null;
	done \
	|sed -n "/^SYNOPSIS/,/^\w/p" \
	|grep '^       \w' \
	|grep -v '[{}]' \
	|sed 's/^[^(]* \**\(\w*\)(.*/\1/' \
	|grep '^\w' \
	|sort \
	|uniq;
}


> 
> Thanks,
> 
> Michael
> 
> 
> 


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

  reply	other threads:[~2021-02-09 23:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <e7685576-db7b-f53d-26b9-64ee6621aea1@gmail.com>
2021-02-08 22:36 ` ptrace.2: Simplify signature? s/enum \w*/int/ Alejandro Colomar (man-pages)
2021-02-09 18:25   ` Michael Kerrisk (man-pages)
2021-02-09 22:34     ` Alejandro Colomar (man-pages) [this message]
2021-02-10 10:18       ` Alejandro Colomar (man-pages)
2021-02-10 10:20         ` Alejandro Colomar (man-pages)
2021-02-10 21:31         ` Michael Kerrisk (man-pages)
     [not found]       ` <CAHBesv0hwHLJMzqBq+e4LpDAWV98H4+d5mv4gSbFFWs8oV7b3w@mail.gmail.com>
     [not found]         ` <20d93fb1-766e-ddf8-a7d8-b00f7bd04cc6@gmail.com>
2021-02-11 17:28           ` Alejandro Colomar (man-pages)
2021-02-13 10:16             ` Alejandro Colomar (man-pages)

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=e5de8f47-b8cc-ee52-4702-5bdf7193f0d8@gmail.com \
    --to=alx.manpages@gmail.com \
    --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 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.