[systemd-devel] Antw: Re: Antw: systemd prerelease 243-rc2

[Ulrich Windl]

>>> Tomasz Torcz <tomek at pipebreaker.pl> schrieb am 22.08.2019 um 19:28 in
Nachricht
<20190822172855.GA159185 at mother.pipebreaker.pl>:
> On Thu, Aug 22, 2019 at 03:38:05PM +0200, Ulrich Windl wrote:
>> >>> systemd tag bot <donotreply-systemd-tag at refi64.com> schrieb am
22.08.2019
>> um
>> 13:56 in Nachricht <20190822115637.1.05C510C92B339AF7 at refi64.com>:
>> > A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the

>> > tarball here:
>> 
>> 
>> >         * On 64 bit systems, the "kernel.pid_max" sysctl is now bumped
to
>> >           4194304 by default, i.e. the full 22bit range the kernel
allows, 
>> > up
>> >           from the old 16bit range. This should improve security and
>> >           robustness, as PID collisions are made less likely (though 
>> 
>> I doubt it's increasing robustness for any existing application as
>> pid_traditionally was 16 bit. I don't know if some applications try to
>> sprintf() a pid into a char[6], but if they do, it might cause an 
> application
>> failure...
> 
>   What kind of tradition would that be?  Could you please point the
> specific standard and implentation?  Everywhere I look pid_t is
> "signed integer type" which is implemented as 32 bits.

pid_t is quite new, also. In System V a pid_t was simply an int, but no PID
ever exceeded 2^15.
That observation could have lead programmers to some false expectations.
Also Using pid_t does not help you to get the correct sprintf buffer size
unless you look how pid_t is actually defined, which -- in turn -- may be
platform-dependent.

Regards,
Ulrich
P.S. From my pearls of UNIX manuals:
---
NAME

getpid – get process identification

SYNOPSIS
getpid( )
DESCRIPTION
Getpid returns the process ID of the current process. Most often it is used to
generate uniquely-named temporary files.
SEE ALSO
mktemp(3)
ASSEMBLER
(getpid = 20.) sys getpid (pid in r0)
---