FD_SETSIZE: signed or unsigned?

Benjamin Kaduk bjk at freebsd.org
Mon Jul 2 20:28:45 UTC 2012

Hi all,

We've had an unsigned FD_SETSIZE since 2002 (r90135, by markm):
Revision 90135 - (show annotations)
Sun Feb 3 11:36:59 2002 UTC (10 years, 5 months ago) by markm
File MIME type: text/plain
File size: 7279 byte(s)

Zero functional difference; make some integer constants unsigned, as
they are used in unsigned context. This shuts lint(1) up in a few
significant ways with "signed/unsigned" arithmetic warnings.

Yet NetBSD, Linux, and OpenBSD all have signed (plain int) FD_SETSIZEs.

This has led to various pieces of software introducing casts and 
workarounds for the FreeBSD behavior, which (apparently) was itself made 
in order to attempt to reduce the occurence of warnings.

Before I go and introduce such workarounds into our codebase for $work, I 
wanted to check with the standards gurus to see whether there is any 
chance that FreeBSD is what needs fixing, first.

Bruce touched on some related issues on freebsd-security a few months 
later in 2002 ("[provos at citi.umich.edu: OpenBSD Security Advisory: Select 
Boundary Condition]"), but I can't really derive anything decisive from 

In any case, it is clear that a negative value for FD_SETSIZE is 
nonsensical.  Doing a quick survey, it seems to mostly be used as the 
first argument to select(2) (which is an int type argument), and as a 
bound check on fd numbers (before using them in select).  Given the 
former, it seems dubious to consider ever using a value between INT_MAX 
and UINT_MAX, which does leave open what the actual type should be.

POSIX is delightfully vague:
The following shall be defined as a macro:


     Maximum number of file descriptors in an fd_set structure.

Further thoughts on the matter are welcome.


More information about the freebsd-standards mailing list