Re: [PATCH v5] grantpt.3: no-op on modern glibc and other UNIXes

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 7375 bytes --]

Hi!

On 2023-07-16 16:52, наб wrote:
> Hi!
> 
> On Sun, Jul 16, 2023 at 03:46:10PM +0200, Alejandro Colomar wrote:
>> On 2023-07-16 13:55, наб wrote:
>> [...]
>>> I read it but didn't really understand what you were saying, since
>>> you're on record as a text‒text‒text liker.
>> In this context, I'm not sure if to read that as that being just
>> emphasis on me being a text liker, which is true-true-true, or if
>> (more likely) "text" are placeholders for random text, and you claim
>> that I'm on record liking no spaces between em dashes.  If it's the
>> latter, I believe I am not, and you might have been confused by some
>> of those records?  Could you point me to the records?
> I think you've said it to me before but I can't strictly find the mail
> (but I'd hopefully blame that on my mail searching).
> 
>> Maybe I had
>> some brain-fart and defended that at some point, but I do not like
>> that style personally.
> Neither do I but I, as usual, consulted the corpus, and it said
>   $ git grep -F '\[em]' | grep -Fe '\[em] ' -e '\[em] ' -c
> to around 160/16 vs -cv.
> 
> Thus, I did what the corpus says.
> 
>> Basically, it is something similar to why we should write punctuation
>> outside of quotes, unless they belong to them, so if I quote someone
>> who said "Hello world!", I include '!' in the quote, as it belongs to
>> the quote, but the ',' belongs to my text.
> This is known (unfairly-)derisively as "programmer punctuation".
> 
>> The reason that I like spaces in (only) one side of em dashes --and I
>> also like closing em dashes even right before other punctuation-- is
>> to make parsing the text less complex.  I've seen cases where in a
>> paragraph, several em-dash asides appear, and it's hard to understand
>> what is the main text and what are the asides, especially when the
>> closing em dash of one of them is omitted.
> The corpus sayeth:

Michael wrote most of that corpus, and that's one of the very few
points where I disagree with him.  I may have written myself some of
those, for continuity with the corpus, but I dislike it.

I may reform all of it to get rid of such cases.  Let's add it to my
TODO list:

-  'Linux v[0-9]\+'  (I see 5 cases.)
-  Logic em dashes.
-  Get rid as much as possible of \f.
-  Transform the remaining \f into \f[].
-  Split proc(5).

>   $ git grep -F '\[em]' | grep -e '\\\[em\] ' -e ' \\\[em\]'  -e ':\\\[em\]' -e '\\\[em\]$' | grep -v @
>   man2/futex.2:.IR "futex word" \[em]whose
>   man2/get_mempolicy.2:.IR nodemask \[em]that
>   man2/ioctl_iflags.2:.IR "inode flags" \[em]attributes
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
>   man2/uname.2:\[em] this is the largest value likely to be encountered in the wild.
>   man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
>   man3type/stat.3type:.RI fields\[em] st_atime ,
>   man3type/stat.3type:.IR st_ctime \[em]typed
>   man4/intro.4:/dev/* \[em] device files
>   man4/st.4:.SS MTIOCTOP \[em] perform a tape operation
>   man4/st.4:.SS MTIOCGET \[em] get status
>   man4/st.4:.SS MTIOCPOS \[em] get tape position
>   man7/man.7:.\" .IP \[em] 3m
>   man7/man.7:.\" .IP \[em]
>   man7/man.7:.\" .IP \[em]
>   man7/man.7:.\" .IP \[em]
>   man7/path_resolution.7:the process \[em] or in the case of
>   man7/tcp.7:Use this option with care \[em] it makes TCP less tolerant to routing
>   man7/unicode.7:Information technology \[em] Universal Multiple-Octet Coded Character
>   man7/unicode.7:Set (UCS) \[em] Part 1: Architecture and Basic Multilingual Plane.
>   man7/x25.7:Message boundaries are preserved \[em] a
> of which these use ‒s as interjective commas:
>   man2/futex.2:.IR "futex word" \[em]whose
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/mbind.2:.BR MAP_ANONYMOUS \[em]or
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
>   man3/grantpt.3:\[em]with permissions configured on pty allotion, as is the case on Linux\[em]\c
> (whoops allotion, should be allocation)

nice catch :)

>   man3type/stat.3type:.RI fields\[em] st_atime ,
>   man3type/stat.3type:.IR st_ctime \[em]typed
> of which these have spacing around the outside:
>   man2/madvise.2:\[em]including tmpfs (see
>   man2/madvise.2:.BR tmpfs (2))\[em]
>   man2/perf_event_open.2:\[em]added, divided (to get ratios), and so on\[em]
> 
> This is, I'm pretty sure, the first time I've encountered this style,
> and it kinda looks like a formatting error to me.
> 
> v6 with
>   op —with permissions configured on pty allocation, as is the case on Linux— or an ioctl(2).
> scissored below.

Thanks!  I'll review later.

Cheers,
Alex

> -- >8 --
> FreeBSD, OpenBSD, and Linux (/dev/ptmx) do all intialisation in open(2),
> and grantpt(3) is a no-op (that checks whether the fd is a pty, except on
> musl).
> 
> The illumos gate and NetBSD do a ioctl (and, indeed, illumos-gate commit
>  facf4a8d7b59fde89a8662b4f4c73a758e6c402c ("PSARC/2003/246 Filesystem
>   Driven Device Naming"), which kills pt_chmod, notes that it's been
>  "6464196 bfu should remove pt_chmod, obsoleted by /dev filesystem").
> 
> glibc 2.33 completely kills BSD PTY support on Linux
> (Debian hasn't configured with them on any architecture since 2007:
>    https://bugs.debian.org/338404
>  and even earlier on some arches; they're really just trivia under
>  Linux ‒ this may be better served stuffed into HISTORY as an explainer
>  for the SIGCHLD thing, since regardless of the "version", the behaviour
>  is well-defined and consistent).
> 
> Cc: Jakub Wilk <jwilk@jwilk.net>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>  man3/grantpt.3 | 18 ++++++++----------
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/man3/grantpt.3 b/man3/grantpt.3
> index a19172a3e..3c753da03 100644
> --- a/man3/grantpt.3
> +++ b/man3/grantpt.3
> @@ -84,17 +84,15 @@ .SH ATTRIBUTES
>  .ad
>  .sp 1
>  .SH VERSIONS
> -Many systems implement this function via a set-user-ID helper binary
> +Historical systems implemented this function via a set-user-ID helper binary
>  called "pt_chown".
> -On Linux systems with a devpts filesystem (present since Linux 2.2),
> -the kernel normally sets the correct ownership and permissions
> -for the pseudoterminal slave when the master is opened
> -.RB ( posix_openpt (3)),
> -so that nothing must be done by
> -.BR grantpt ().
> -Thus, no such helper binary is required
> -(and indeed it is configured to be absent during the
> -glibc build that is typical on many systems).
> +glibc on Linux before glibc 2.33 could do so as well,
> +in order to support configurations with only BSD pseudoterminals;
> +this support has been removed.
> +On modern systems this is either a no-op
> +\[em]with permissions configured on pty allocation, as is the case on Linux\[em]
> +or an
> +.BR ioctl (2).
>  .SH STANDARDS
>  POSIX.1-2008.
>  .SH HISTORY

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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