<div dir="ltr"><div>With the risk of sidetracking from the original question...</div><div><br></div>At a theoretical level, I prefer separating functions implementing policies, and functions implementing mechanisms. "Mechanism" functions do one specific thing. There are no exceptions or corner cases. "Policy" functions, deal with the exceptions. They implement a policy, i.e. they make a specific decision on how to handle a certain case. As an example, "platform A has no user concept, so I will always return uid 0, which is root". Another policy function could implement the policy "platform A has no user concept, so I will throw an exception". When you confuse, or merge, the two, you limit the opportunity to implement other policies. If you have the "mechanism" functions, you can implement whatever policy suits you. If you only have the policy function, the corner cases are going to bite you somewhere down the road.<div><br></div><div>With this reasoning, having a posix module makes sense, because that is a "mechanism" thing. If I want to implement a generic function that works similar on both Windows and posix, I can put that in a separate module, which describes the chosen policy (i.e. the trade-offs made).</div><div><div><br></div><div>getuid is probably not a good example here, because it is likely to make sense on most, if not all, platforms, but I hope you get the idea.<div><br></div><div>I hope I didn't side-track the discussion too much.</div></div></div></div>