12:56:19 hello. im writing from rust libc project. i'm hoping to get comment on this: https://github.com/rust-lang/libc/pull/2914#issuecomment-1264351115 12:57:15 essentially, there are no POSIX-conforming versions of getpwent_r and getgrent_r in illumos. i didn't notice this in 2017, and patched rust libc to refer to non-existent functions since CI passed (there are too many platforms to individually test) 12:57:53 now that this issue has existed a while, i want to patch illumos to add the POSIX-conforming versions. there's a competing theory that rust-libc should change its API. 12:58:01 what would illumos devs rather happen? 12:59:56 There should be POSIX-conforming versions available if the right standard is selected IIRC 13:00:35 I think illumos still defaults to POSIX.1c, Draft 6 for these, which is troublesome 13:00:47 See the comment below https://github.com/illumos/illumos-gate/blob/master/usr/src/head/pwd.h#L72 13:01:06 and https://illumos.org/man/7/standards 13:05:08 I misremembered, I was thinking of getpwuid_r() 13:06:29 but what was done for that, could be done for getpwent_r and getgrent_r too (define __posix variants and select them based on the requested standard) 13:10:35 andyf: is that the right solution though? as i see it there are two main things that can happen and i don't know which is worse 13:10:48 I can't actually find getpwent_r and getgrent_r in the POSIX standard 13:10:53 getpwnam_r and getpwuid_r are there 13:12:30 i see, right, the original comment to rust/libc#2914 does say there are no conforming versions. but the versions assumed to be there in 2017 are really common. 13:12:46 the issue is that in the man pages there are section called "Standard conforming" 13:13:03 but i think actually there is no standard lol to which it is referring, man pages are wrong 13:13:09 The illumos man pages? 13:13:16 The linux ones seem to say "These functions are GNU extensions" 13:13:38 I don't know the history but it seems like Solaris and glibc evolved different variants of these.. which does not help you 13:13:57 hmmm i thought i saw it in a bsd manpage 13:14:03 (bsd does have the functions) 13:15:08 https://www.freebsd.org/cgi/man.cgi?getpwent_r#end 13:15:39 So getpwent(), getpwnam(), getpwnam_r(), getpwuid(), getpwuid_r(), setpwent(), and endpwent() are POSIX 13:15:53 https://docs.oracle.com/cd/E88353_01/html/E37843/getpwent-r-3c.html 13:16:32 right okay. well would you rather, then, that POSIX-like versions _not_ be added then? 13:16:38 since it isn't right to call them conforming 13:16:43 even if they are in linux, bsd 13:18:45 cf. https://man.netbsd.org/getpwent_r.3 for the BSD versions 13:18:58 seems like Solaris and forks is the odd one out 13:20:08 It does, yes, and we always want to try and improve compatibility and make it easier to build things on illumos, which has meant adding GNU extensions and things in the past 13:22:28 ok so maybe i should add them as e.g. __posixlike_getpwent_r 13:22:34 and not __posix_getpwent_r 13:22:38 and patch rust/libc as well 13:22:53 that way it's clear that someething went wrong? 13:23:05 or even __gnu or __bsd 13:23:13 (dont really know the naming conventions) 13:24:06 I think we should try and do something, I'm just not sure what the best approach is (and the people who will have a better idea are probably still asleep) 13:24:39 we can define the symbol with any name that makes sense (just not __posix since it is not) - the tricky part is how software knows to select the different function definition 13:25:15 and how we stop breaking everything that knows about the illumos posix-draft-like variants 13:28:04 I have to head out for a bit but will be around later and this channel is usually more active then. 13:29:25 I'd summarise as. These are not POSIX, glibc and freebsd have grown posix-like variants which are different to the posix-like variants that we inherited from Solaris. How do we make things better for third party software? 13:41:59 thanks andyf. can i post this log in the rust/libc issue? 15:34:58 FWIW, i don't see any issues with tmux (3.3 though) after #14788, running debug 18:30:00 yuripv - in 3.3 they disabled event ports completely 18:30:24 https://github.com/tmux/tmux/issues/2702 18:31:27 If I rebuild tmux with that patch backed out, I see the problem that's reported in 15031 18:55:11 ah, i see 19:17:48 though the issue says it was that way for a long time? 19:25:25 Whatever it was that made them disable event ports in tmux seems to be a different issue, and I can't replicate it on current bits so perhaps it was fixed in the interim. 19:25:49 But since 3.3 is not using event ports, it does not get affected by 14788 19:30:51 some of the discussion about this seems like it's going interesting places and maybe should land in a big comment in the code somewhere 19:30:58 (unless all the bits that seem a bit odd get cleaned up)