hello. im writing from rust libc project. i'm hoping to get comment on this: rust-lang/libc #2914#issuecomment-1264351115

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)

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.

what would illumos devs rather happen?

There should be POSIX-conforming versions available if the right standard is selected IIRC

I think illumos still defaults to POSIX.1c, Draft 6 for these, which is troublesome

See the comment below github.com/illumos/illumos-gate/blob/master/usr/src/head/pwd.h#L72

and illumos.org/man/7/standards

I misremembered, I was thinking of getpwuid_r()

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)

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

I can't actually find getpwent_r and getgrent_r in the POSIX standard

getpwnam_r and getpwuid_r are there

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.

the issue is that in the man pages there are section called "Standard conforming"

but i think actually there is no standard lol to which it is referring, man pages are wrong

The illumos man pages?

The linux ones seem to say "These functions are GNU extensions"

I don't know the history but it seems like Solaris and glibc evolved different variants of these.. which does not help you

hmmm i thought i saw it in a bsd manpage

(bsd does have the functions)

So getpwent(), getpwnam(), getpwnam_r(), getpwuid(), getpwuid_r(), setpwent(), and endpwent() are POSIX

right okay. well would you rather, then, that POSIX-like versions _not_ be added then?

since it isn't right to call them conforming

even if they are in linux, bsd

cf. man.netbsd.org/getpwent_r.3 for the BSD versions

seems like Solaris and forks is the odd one out

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

ok so maybe i should add them as e.g. __posixlike_getpwent_r

and not __posix_getpwent_r

and patch rust/libc as well

that way it's clear that someething went wrong?

or even __gnu or __bsd

(dont really know the naming conventions)

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)

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

and how we stop breaking everything that knows about the illumos posix-draft-like variants

I have to head out for a bit but will be around later and this channel is usually more active then.

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?

thanks andyf. can i post this log in the rust/libc issue?

FWIW, i don't see any issues with tmux (3.3 though) after #14788, running debug

yuripv - in 3.3 they disabled event ports completely

If I rebuild tmux with that patch backed out, I see the problem that's reported in 15031

ah, i see

though the issue says it was that way for a long time?

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.

But since 3.3 is not using event ports, it does not get affected by 14788

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

(unless all the bits that seem a bit odd get cleaned up)