On Mon, 2012-02-27 at 18:11 +0100, Mark Kettenis wrote: > Neither does OpenBSD. And POSIX doesn't seem to mention it either. > So this smells like a Linux-specific extension. Or perhaps more > accurately, a glibc-specific extension.
http://netbsd.gw.com/cgi-bin/man-cgi?fopen++NetBSD-current I admit I hadn't checked OpenBSD or FreeBSD though. > So you should change the > #ifdefs around I think. Or perhaps go the protable route using > fileno(3) and fcntl(2). I don't think atomicity is a real requirement > here. If you want the bug to be actually fixed instead of just almost fixed, atomicity is the whole point and is absolutely a requirement. Even if we're assuming userspace threads like OpenBSD instead of real threads like everything else, this is still a real race. In case this isn't clear, the sequence looks like: int one = 1; FILE *fp = fopen(path, mode); int fd = fileno(fp); fcntl(fd, FD_CLOEXEC, &one); And OpenBSD's thread scheduler alarm signal is perfectly capable of firing (and switching tasks) between when fopen() returns and fcntl hits the kernel, there's easily a few dozen instructions between those points. (Yes, I did go read the source.) I'll concede that pci.ids isn't a hardware resource, and in that sense it's not a huge deal whether fopen() works right. But I would have expected an OS that prides itself so much on using safe APIs all the time to want to use safe APIs all the time. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
