>>> Tomasz Torcz <tomek@xxxxxxxxxxxxxx> schrieb am 22.08.2019 um 19:28 in Nachricht <20190822172855.GA159185@xxxxxxxxxxxxxxxxxxxxx>: > On Thu, Aug 22, 2019 at 03:38:05PM +0200, Ulrich Windl wrote: >> >>> systemd tag bot <donotreply-systemd-tag@xxxxxxxxxx> schrieb am 22.08.2019 >> um >> 13:56 in Nachricht <20190822115637.1.05C510C92B339AF7@xxxxxxxxxx>: >> > 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) --- _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel