On Tuesday January 24 2017 19:14:28 Brandon Allbery wrote:
>On Tue, Jan 24, 2017 at 6:53 PM, René J.V. Bertin <[email protected]>
>wrote:
>
>> 0775 (00000001:11111101) turning into 0255 (0000000:10101101), there's no
>> logical explanation (involving umask()) for that, is there?
>That is what you'd get if the *umask* were 0255.
Why yes indeed, but then the question becomes why the umask would sometimes get
set to 0255. Does that sound like a value that base might use in certain
conditions? I never use umask myself, one of those things I shoot myself in the
foot with too easily.
The setmode() manpage warns about transient changes to umask (on Linux and OS
X) but the only evidence I find for that (in v. 0.8.3) is this:
{{{
/*
* Get a copy of the mask for the permissions that are mask relative.
* Flip the bits, we want what's not set. Since it's possible that
* the caller is opening files inside a signal handler, protect them
* as best we can.
*/
sigfillset(&signset);
(void)sigprocmask(SIG_BLOCK, &signset, &sigoset);
(void)umask(mask = umask(0));
mask = ~mask;
(void)sigprocmask(SIG_SETMASK, &sigoset, NULL);
}}}
I don't know what the umask() function does internally but I'd hope that would
be one of the more exhaustively tested (and no-longer-evolving) system
functions. Maybe the old-style obfuscated-C like umask() statement can confuse
modern-day optimisers in such a way that the operation has side-effects under
stress? Sounds unlikely, no?
Am I missing a reason why the umask() function would interact with the
filesystem?
R.
