This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid undefined behavior in __FD_MASK


On 06/11/2013 06:40 PM, OndÅej BÃlka wrote:
On Fri, Apr 12, 2013 at 10:29:33AM +0200, Florian Weimer wrote:
On 04/11/2013 10:32 PM, Roland McGrath wrote:
__fd_mask
should really be an unsigned type, but changing that is more risky.

That really is the right fix (and then your change is unnecessary).
What risks do you imagine with the type change?

The fd_bits member used to be part of the public API in the 90s, and
someone might point a long * variable to it.  There's also a
comment:

/* The fd_set member is required to be an array of longs.  */
typedef long int __fd_mask;

If someone still has the discussion to Austin group issue
bwg2001-005 (which led to the removal of the fd_bits member), it
might shed some light onto this.

But I'm probably overly conservative here.

Besides select.h files I can find fd_mask only in
sunrpc/svc.c, how would unsigned change this.

I am ok with this patch.

Sorry, it turns out that we check that fd_mask is a plain long via scripts/check-c++-types.sh. It's sort-of part of the ABI, it seems.

Should I drop fd_mask from the checking, adjust the test results, or go with my original patch which does not change the type?

--
Florian Weimer / Red Hat Product Security Team


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]