On 04/13/16 08:41, Colin Walters wrote: > On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote: > >> It's not possible to read the process umask without also modifying it, >> which is what umask(2) does. A library cannot read umask safely, >> especially if the main program might be multithreaded. > > I assume you just want to do this from a shared library so you can > determine whether or not you need to call fchown() after making files > and the like? If that's the case it'd be good to note it in the commit > message. > > BTW...it might be a good idea to add a flags argument: > https://lwn.net/Articles/585415/ > > Did you consider calling this `umask2`, having the initial version only support > retrieving it via a UMASK_GET flag, and lay the groundwork to support > setting a threadsafe umask with a UMASK_SET_THREAD flag? > The comments on that article also list a number of problems with this approach, related to how undefined flags are handled. In fact, if it wasn't for this exact problem then umask(-1) would have been the logical way to deal with this, but because umask(2) is defined to have an internal & 07777 it becomes infeasible at least in theory. In practice it might work... However, see previous discussions about making this available in /proc. Also, I really think there is something to be said for a O_NOUMASK option... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
