cvs commit: src/lib/libutil pidfile.3

Giorgos Keramidas keramida at
Fri Mar 3 04:40:28 PST 2006

On 2006-03-03 10:15, Ruslan Ermilov <ru at> wrote:
>On Fri, Mar 03, 2006 at 04:43:09AM +0200, Giorgos Keramidas wrote:
>>On 2006-01-28 14:13, Pawel Jakub Dawidek <pjd at> wrote:
>>> Modified files:
>>>   lib/libutil          pidfile.3
>>> Log:
>>> [...]
>>> - Cast pid_t to int.
>> Hi Pawel,
>> Doesn't it make more sense to cast pid_t to intmax_t, or is it
>> by definition always <= int?
> POSIX only requires that "blksize_t, pid_t, and ssize_t shall
> be signed integer types."

Right.  I got so far, but asked to make sure I didn't miss
anything important elsewhere.

Thanks Ruslan :)

On 2006-03-03 22:05, Bruce Evans <bde at> wrote:
> I always cast pid_t to long for printing.  This was correct
> before C99 broke the promise that long was the longest signed
> integer type.

Which sucks a bit, but is not something we can change now :(

> In practice, PID_MAX is 30000 in 4.4BSD, so casting to int was
> enough even on systems with 16-bit ints.  FreeBSD changed
> PID_MAX to 99999 on 13 Nov 1998, but FreeBSD never supported
> any systems with 16-bit ints, so casting to int has always
> worked on FreeBSD.  It is just unportable.

Which is exactly why I was a bit worried seeing this documented
in the manpages.  I'm ok with using unportable constructs in
places where there is no portable equivalent, but documenting
stuff that users will start copying as authoritative ``because I
saw it in this and that FreeBSD manpage'' is probably not ok.

Any objections for changing `int' to `intmax_t' or, at least,
`long' in the manpage examples?

More information about the cvs-src mailing list