question for the "base gurus"

[René J.V. Bertin]

On Tuesday January 24 2017 19:14:28 Brandon Allbery wrote:
>On Tue, Jan 24, 2017 at 6:53 PM, René J.V. Bertin <rjvbertin at gmail.com>
>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.