Re:Poll on macOS 10.12 is broken
by JdeBP on Tuesday October 11, 2016 @06:47PM
(#12689141)
Ironically, given all of the commentary about whether it's conformant for an array passed to a function to have NULL as its starting address, that is not actually the bug here. The bug, as indirectly explained by the headlined article, is actually to do with the array length being zero.
[ Parent
| on HN ]
Possibly, but that's not what' exercised by the minimal test case, supposedley demonstrating the issue in the article.
Returning immediately with a non null fds, a zero lenght and non zero timeout is unarguably a bug.
The array length is zero in that code.
which is irrelevant, as the null pointer passed to poll triggers UB before the length of the array enters into the picture.
To repeat: The NULL pointer is not the locus of the bug, and this was explained by the detailed discussion from the headlined article. The NULL pointer for the array base is passed to copyin() and copyout() without incident, and those are its only uses by poll().
To repeat: my point is that the test case shown in the article and described in the bug cannot be used to reliably identify a broken poll as passing NULL for fds is, strictly speaking, UB.
I'm not making any claim about the actual source of the poll bug here.
At https://news.ycombinator.com/item?id=12689472 that's exactly what you stated, and you were wrong. The test case has a zero length array; that it what it is exercising; and that is the locus of the bug, as the headlined article's detailed discussion makes clear.