[PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[Seth McDonald]

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

Heya all,

Continuing the updating of HISTORY sections, this patch set regards
system calls whose identifiers start with A through CH.  This time, more
care was taken to ensure any modified lists are given in a somewhat
chronological order.

As hinted at previously on this list, searching for a *truely*
chronological ordering is likely a futile effort given the seemingly
circular influences between many early systems.  But an approximation of
this ordering based on our limited information can still be useful.
Which is the attitude with which these patches were made.

And on another note, I think I've found a way to stop Proton Mail from
corrupting patches.  So my patches should henceforth all be PGP-signed,
assuming my workaround is sufficient.

Seth McDonald (19):
  man/man2/access.2: HISTORY: Update first POSIX appearance of access(2)
  man/man2/access.2: HISTORY: Specify different access(2) prototypes
  man/man2/access.2: HISTORY: Update first POSIX appearance of
    faccessat(2)
  man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2)
  man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2)
  man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2)
  man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes
  man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2)
  man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2)
  man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2)
  man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes
  man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2)
  man/man2/chmod.2: HISTORY: Update first POSIX appearance of
    AT_SYMLINK_NOFOLLOW
  man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2)
  man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2)
  man/man2/chown.2: HISTORY: Specify different chown(2) prototypes
  man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2)
  man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2)
  man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)

 man/man2/access.2 | 14 ++++++++++++--
 man/man2/alarm.2  |  4 +++-
 man/man2/chdir.2  | 20 +++++++++++++++++++-
 man/man2/chmod.2  | 18 ++++++++++++++++--
 man/man2/chown.2  | 24 +++++++++++++++++++++---
 man/man2/chroot.2 |  5 ++++-
 6 files changed, 75 insertions(+), 10 deletions(-)

Range-diff against v0:
 -:  ------------ >  1:  58a0a70c6308 man/man2/access.2: HISTORY: Update first POSIX appearance of access(2)
 -:  ------------ >  2:  d87c7800e0f5 man/man2/access.2: HISTORY: Specify different access(2) prototypes
 -:  ------------ >  3:  7e6b054be57e man/man2/access.2: HISTORY: Update first POSIX appearance of faccessat(2)
 -:  ------------ >  4:  51224c3d2e6c man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2)
 -:  ------------ >  5:  c6961e073ad1 man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2)
 -:  ------------ >  6:  61d257dc5032 man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2)
 -:  ------------ >  7:  b367400491b2 man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes
 -:  ------------ >  8:  d6316545d253 man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2)
 -:  ------------ >  9:  ce5b927c6695 man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2)
 -:  ------------ > 10:  de87aa2b3e28 man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2)
 -:  ------------ > 11:  02eef8835d60 man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes
 -:  ------------ > 12:  691b1ee71099 man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2)
 -:  ------------ > 13:  bc1d06a06e9e man/man2/chmod.2: HISTORY: Update first POSIX appearance of AT_SYMLINK_NOFOLLOW
 -:  ------------ > 14:  2981d5702b65 man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2)
 -:  ------------ > 15:  fccd134bc9d7 man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2)
 -:  ------------ > 16:  ece23c04dc89 man/man2/chown.2: HISTORY: Specify different chown(2) prototypes
 -:  ------------ > 17:  bf9099a04c4f man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2)
 -:  ------------ > 18:  5abf94a520b5 man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2)
 -:  ------------ > 19:  fd08b4cf0a52 man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)

base-commit: 91fa6d909b1171bc2361b5b2192c11c8be06a7d1
-- 
2.47.3


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

Re: [PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[Alejandro Colomar]

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

Hi Seth,

On Mon, Jan 19, 2026 at 11:54:29AM +0000, Seth McDonald wrote:
> Heya all,
> 
> Continuing the updating of HISTORY sections, this patch set regards
> system calls whose identifiers start with A through CH.  This time, more
> care was taken to ensure any modified lists are given in a somewhat
> chronological order.
> 
> As hinted at previously on this list, searching for a *truely*
> chronological ordering is likely a futile effort given the seemingly
> circular influences between many early systems.  But an approximation of
> this ordering based on our limited information can still be useful.
> Which is the attitude with which these patches were made.

Thanks!  I've applied most patches.  The ones that document non-const
old prototypes, I've not applied those; all others have been applied.

> And on another note, I think I've found a way to stop Proton Mail from
> corrupting patches.  So my patches should henceforth all be PGP-signed,
> assuming my workaround is sufficient.

Yup; that worked!  All patches were correctly signed, and none were
corrupted (or at least I didn't notice).  Out of curiosity, what was the
workaround?  And how did you sign the patches?  Was it with neomutt(1)?  


Have a lovely night!
Alex

> 
> Seth McDonald (19):
>   man/man2/access.2: HISTORY: Update first POSIX appearance of access(2)
>   man/man2/access.2: HISTORY: Specify different access(2) prototypes
>   man/man2/access.2: HISTORY: Update first POSIX appearance of
>     faccessat(2)
>   man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2)
>   man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2)
>   man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2)
>   man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes
>   man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2)
>   man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2)
>   man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2)
>   man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes
>   man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2)
>   man/man2/chmod.2: HISTORY: Update first POSIX appearance of
>     AT_SYMLINK_NOFOLLOW
>   man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2)
>   man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2)
>   man/man2/chown.2: HISTORY: Specify different chown(2) prototypes
>   man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2)
>   man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2)
>   man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)
> 
>  man/man2/access.2 | 14 ++++++++++++--
>  man/man2/alarm.2  |  4 +++-
>  man/man2/chdir.2  | 20 +++++++++++++++++++-
>  man/man2/chmod.2  | 18 ++++++++++++++++--
>  man/man2/chown.2  | 24 +++++++++++++++++++++---
>  man/man2/chroot.2 |  5 ++++-
>  6 files changed, 75 insertions(+), 10 deletions(-)
> 
> Range-diff against v0:
>  -:  ------------ >  1:  58a0a70c6308 man/man2/access.2: HISTORY: Update first POSIX appearance of access(2)
>  -:  ------------ >  2:  d87c7800e0f5 man/man2/access.2: HISTORY: Specify different access(2) prototypes
>  -:  ------------ >  3:  7e6b054be57e man/man2/access.2: HISTORY: Update first POSIX appearance of faccessat(2)
>  -:  ------------ >  4:  51224c3d2e6c man/man2/alarm.2: HISTORY: Update first POSIX appearance of alarm(2)
>  -:  ------------ >  5:  c6961e073ad1 man/man2/chdir.2: HISTORY: Split chdir(2) and fchdir(2)
>  -:  ------------ >  6:  61d257dc5032 man/man2/chdir.2: HISTORY: Update first POSIX appearance of chdir(2)
>  -:  ------------ >  7:  b367400491b2 man/man2/chdir.2: HISTORY: Specify different chdir(2) prototypes
>  -:  ------------ >  8:  d6316545d253 man/man2/chdir.2: HISTORY: Update first POSIX appearance of fchdir(2)
>  -:  ------------ >  9:  ce5b927c6695 man/man2/chmod.2: HISTORY: Split chmod(2) and fchmod(2)
>  -:  ------------ > 10:  de87aa2b3e28 man/man2/chmod.2: HISTORY: Update first POSIX appearance of chmod(2)
>  -:  ------------ > 11:  02eef8835d60 man/man2/chmod.2: HISTORY: Specify different chmod(2) prototypes
>  -:  ------------ > 12:  691b1ee71099 man/man2/chmod.2: HISTORY: Update first POSIX appearance of fchmod(2)
>  -:  ------------ > 13:  bc1d06a06e9e man/man2/chmod.2: HISTORY: Update first POSIX appearance of AT_SYMLINK_NOFOLLOW
>  -:  ------------ > 14:  2981d5702b65 man/man2/chown.2: HISTORY: Split chown(2), fchown(2), and lchown(2)
>  -:  ------------ > 15:  fccd134bc9d7 man/man2/chown.2: HISTORY: Update first POSIX appearance of chown(2)
>  -:  ------------ > 16:  ece23c04dc89 man/man2/chown.2: HISTORY: Specify different chown(2) prototypes
>  -:  ------------ > 17:  bf9099a04c4f man/man2/chown.2: HISTORY: Update first SUS appearance of fchown(2)
>  -:  ------------ > 18:  5abf94a520b5 man/man2/chown.2: HISTORY: Update first POSIX appearance of lchown(2)
>  -:  ------------ > 19:  fd08b4cf0a52 man/man2/chroot.2: HISTORY: Update first SUS appearance of chroot(2)
> 
> base-commit: 91fa6d909b1171bc2361b5b2192c11c8be06a7d1
> -- 
> 2.47.3
> 



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

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

Re: [PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[Seth McDonald]

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

Hi Alex,

On Tue, Jan 20, 2026 at 02:50:22AM +0100, Alejandro Colomar wrote:
> Hi Seth,
> 
> On Mon, Jan 19, 2026 at 11:54:29AM +0000, Seth McDonald wrote:
[...]
> > And on another note, I think I've found a way to stop Proton Mail from
> > corrupting patches.  So my patches should henceforth all be PGP-signed,
> > assuming my workaround is sufficient.
> 
> Yup; that worked!  All patches were correctly signed, and none were
> corrupted (or at least I didn't notice).  Out of curiosity, what was the
> workaround?

tl;dr: The solution was surprisingly simple: just always use
quoted-printable or base64 for the email's transfer encoding.

Because I did not want to associate my Gmail address with my PGP key(s)
(I very rarely use it), I spent a good while trying to figure out why
Proton Mail was corrupting my patches.  And specifically, I continually
experimented with different patches to see if I could predict exactly
when and where any corruption would occur (scientific method ftw!).

This included trying out different combinations of options for
git-send-email(1), including those which I previously had no
understanding of.  And I eventually found that, given the same email,
executing git-send-email(1) with the --transfer-encoding option set to
'7bit' or '8bit' would produce the same corrupted patch, but with it set
to 'quoted-printable' or 'base64' the patch would remain intact.

I also found that the mangling was deterministic.  The same email is
always mangled the same way.  And the mangling always occurs via the
insertion of line breaks into the email contents.

Not only that, but (and this is the weirdest part) if we treat line
breaks as two characters (i.e. as CRLF), then every line break is
inserted exactly every 1000 characters.  If you go back to the first
corrupted patch I sent in and count from the start of the text/plain
contents, you should find two out-of-place line breaks both 1000
characters apart (again, counting line breaks as two characters).

After doing some research with this information, my guess as to what's
happening is Proton Mail is getting an email from an external source,
and checking it to ensure it conforms to the semantics of the specified
content transfer encoding.  Including that lines are no longer than 998
characters and line breaks use CRLF when using 7bit or 8bit encodings.
But may not correctly reset its line length/character count to zero when
encountering an LF and changing it to CRLF.  And so thinks that the
email is one giant line, and inserts line breaks every 1000 characters
to "fix" it.

This is just a guess though.  And regardless of the actual cause, I've
reported the bug with this information (and more) to Proton.  So
hopefully it'll be fixed sometime.

> And how did you sign the patches?  Was it with neomutt(1)?  

The way I set up my email workflow is with Proton Mail Bridge, which
creates a local SMTP server I can use to send emails via mutt(1),
git-send-email(1), etc.  I have it configured to by default sign all
emails I send with the corresponding PGP key.  That way, any email I
send with mutt(1) or git-send-email(1) should be automatically signed.

Now, yes, I am aware that a third party (Proton) having access to an
(encrypted w/ my password) store of the private key I use can arguably
defeat the purpose of using PGP.  After all, only *I* should ever have
access to it.  And in principle I 100% agree.  But since my personal
threat model currently doesn't include being a state target, I don't
see the need to change my workflow.  (But who knows, seeing how the US
is currently going, I may be compelled to change that...)

Besides, I also have a separate PGP key I keep *only* on a physical
security key which I use for most non-email situations.  Such as
encrypting documents and signing commits.  If I ever need extra
assurance for authenticity or encryption, this is the key I use.

-- 
Take care,
	Seth McDonald.

On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289


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

Re: [PATCH v1 00/19] man/man2/*: Update history of syscalls A-CH

[Alejandro Colomar]

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

Hi Seth,

On Wed, Jan 21, 2026 at 11:14:34AM +0000, Seth McDonald wrote:
> Hi Alex,
> 
> On Tue, Jan 20, 2026 at 02:50:22AM +0100, Alejandro Colomar wrote:
> > Hi Seth,
> > 
> > On Mon, Jan 19, 2026 at 11:54:29AM +0000, Seth McDonald wrote:
> [...]
> > > And on another note, I think I've found a way to stop Proton Mail from
> > > corrupting patches.  So my patches should henceforth all be PGP-signed,
> > > assuming my workaround is sufficient.
> > 
> > Yup; that worked!  All patches were correctly signed, and none were
> > corrupted (or at least I didn't notice).  Out of curiosity, what was the
> > workaround?
> 
> tl;dr: The solution was surprisingly simple: just always use
> quoted-printable or base64 for the email's transfer encoding.
> 
> Because I did not want to associate my Gmail address with my PGP key(s)
> (I very rarely use it), I spent a good while trying to figure out why
> Proton Mail was corrupting my patches.  And specifically, I continually
> experimented with different patches to see if I could predict exactly
> when and where any corruption would occur (scientific method ftw!).
> 
> This included trying out different combinations of options for
> git-send-email(1), including those which I previously had no
> understanding of.  And I eventually found that, given the same email,
> executing git-send-email(1) with the --transfer-encoding option set to
> '7bit' or '8bit' would produce the same corrupted patch, but with it set
> to 'quoted-printable' or 'base64' the patch would remain intact.
> 
> I also found that the mangling was deterministic.  The same email is
> always mangled the same way.  And the mangling always occurs via the
> insertion of line breaks into the email contents.
> 
> Not only that, but (and this is the weirdest part) if we treat line
> breaks as two characters (i.e. as CRLF), then every line break is
> inserted exactly every 1000 characters.  If you go back to the first
> corrupted patch I sent in and count from the start of the text/plain
> contents, you should find two out-of-place line breaks both 1000
> characters apart (again, counting line breaks as two characters).
> 
> After doing some research with this information, my guess as to what's
> happening is Proton Mail is getting an email from an external source,
> and checking it to ensure it conforms to the semantics of the specified
> content transfer encoding.  Including that lines are no longer than 998
> characters and line breaks use CRLF when using 7bit or 8bit encodings.
> But may not correctly reset its line length/character count to zero when
> encountering an LF and changing it to CRLF.  And so thinks that the
> email is one giant line, and inserts line breaks every 1000 characters
> to "fix" it.
> 
> This is just a guess though.  And regardless of the actual cause, I've
> reported the bug with this information (and more) to Proton.  So
> hopefully it'll be fixed sometime.

Wow!  Nice analysis!  I hope they fix it.  :)

> > And how did you sign the patches?  Was it with neomutt(1)?  
> 
> The way I set up my email workflow is with Proton Mail Bridge, which
> creates a local SMTP server I can use to send emails via mutt(1),
> git-send-email(1), etc.  I have it configured to by default sign all
> emails I send with the corresponding PGP key.  That way, any email I
> send with mutt(1) or git-send-email(1) should be automatically signed.
> 
> Now, yes, I am aware that a third party (Proton) having access to an
> (encrypted w/ my password) store of the private key I use can arguably
> defeat the purpose of using PGP.  After all, only *I* should ever have
> access to it.  And in principle I 100% agree.  But since my personal
> threat model currently doesn't include being a state target, I don't
> see the need to change my workflow.  (But who knows, seeing how the US
> is currently going, I may be compelled to change that...)
> 
> Besides, I also have a separate PGP key I keep *only* on a physical
> security key which I use for most non-email situations.  Such as
> encrypting documents and signing commits.  If I ever need extra
> assurance for authenticity or encryption, this is the key I use.

Thanks!  I'll keep that in mind for special situations.  For now, if
it's more comfortable to you, I guess what you're corrently doing is
relatively fine.  But as you say, it might not be a good idea in the
long term.  ;)


Cheers,
Alex

> -- 
> Take care,
> 	Seth McDonald.
> 
> On-list:  2336 E8D2 FEB1 5300 692C  62A9 5839 6AD8 9243 D369
> Off-list: 82B9 620E 53D0 A1AE 2D69  6111 C267 B002 0A90 0289

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

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