> Both are available if you use --std=c89 on gcc and clang.
This is irrelevant - that switch doesn’t have anything to do with controlling functionality not provided by the C standard library. Since poll and select aren’t part of it to begin with it doesn’t affect their availability.
epoll and signalfd will be available (on a gcc target where they are available obviously) as well with that switch I don’t think that makes them C standard library functionality.
select/poll differs enough across common platforms. In MSVC, poll isn’t there, sure you can emulate but now the goal post moving is getting ridiculous. The arguments to select are only superficially compatible (A practical example is that POSIX select supports pipes, but this will not work on Windows outside of specific environments or 3rd party implementations)
"WSAPoll" because it's not a POSIX poll even though the signature is the same at it works similarly for sockets and I guess Microsoft thought through it better 15 years later.
But the original claim is just that select/poll are "everywhere it makes sense", but this depends on what you define select/poll to be. I think something close to POSIX is what makes sense. If you can't use it on pipes and FIFOs (and even regular files without getting an error) that seems like a pretty contrived definition.
The whole moving around of definition of what is the C standard library just because of popularity seems unproductive. ("You can do nonblocking IO using the C std library." -- no, you can't) Most popular 3rd party libraries support or can easily support the most popular targets due in large part to them being popular, that means "in practice, they exist everywhere it makes sense." Does this mean all popular 3rd party libraries are part of the C standard library?
Colloquially redefining terms like what is the C standard library just sows confusion with no benefit (as was illustrated earlier in regards to threads; C11 threads are not pthreads), just say what you mean in this case.
Yes, it is remarkable what little you actually get when you strictly stick to the actual C89/C99/C11 definitions of what's in "The C Standard Library". I still get tripped up on it, and often have to double check: Surely sigaction() is part of the C Standard! NOPE it's POSIX, but signal() is! Surely strptime() is part of the standard! NOPE, but strftime() is. termios stuff? NOPE. It's a minefield out there.
This is irrelevant - that switch doesn’t have anything to do with controlling functionality not provided by the C standard library. Since poll and select aren’t part of it to begin with it doesn’t affect their availability.
epoll and signalfd will be available (on a gcc target where they are available obviously) as well with that switch I don’t think that makes them C standard library functionality.
select/poll differs enough across common platforms. In MSVC, poll isn’t there, sure you can emulate but now the goal post moving is getting ridiculous. The arguments to select are only superficially compatible (A practical example is that POSIX select supports pipes, but this will not work on Windows outside of specific environments or 3rd party implementations)