Conversation
|
This doesn't work for POLLPRI This means it breaks ftpd's transfer cancellation mechanism The wiki says: 0x08 and 0x10 are both set when the socket is writable, so I will assume those are POLLWRNORM(POLLOUT) and POLLWRBAND respectively as you have written I haven't been able to find any situation that triggers 0x04, 0x20, 0x40, or 0x80 If 0x80 truly is POLLNVAL then libctru should totally prevent that because of the newlib/ctru fd translation. If it's not a valid ctru socket descriptor then it will fail to translate and return ENODEVICE (the whole poll() fails) |
|
I think it would probably be acceptable if #define POLLPRI (POLLRDBAND | 0x04) |
|
Upon further inspection I can't find any path in the code that can trigger 0x04, 0x40, or 0x80. POLLNVAL is also 0x20 indeed, that is my bad. The write flags are probably right, since when flag 0x10 is set, flag 0x8 is always set too. And on UDP the only revents returned are either 0x1 (POLLIN) or 0x9 (POLLIN | POLLWRBAND) Surprisingly, the module adds |
|
Sorry if this hasn't been responded to yet -- I'll try to have a look again this week |
The write flags for poll events were wrong,
0x8is used forPOLLWRNORM/POLLOUTand0x10meansPOLLWRBAND. These values closely resemble the Wii sockets, though not all values are the same. The reverse engineered sysmodule shows that flags0x4,0x40and0x80aren't returned in any code path, even though the sysmodule sets0x40and0x80along with0x20on the input events, which should mean error flags.The values have been verified when reverse engineering the socket sysmodule, and has been tested with various applications: