chmod -x fails, apparently due to umask

(note that the same test succeeds with umask 022)

The resulting file permissions are correct, according to the manpage:

If none of [the letters ‘ugoa’] are given, the effect is as if ‘a’ were given, but bits that are set in the umask are not affected.

At first I thought the exit code of 1 was a mistake, but it's not either. From the source:

/* If true, diagnose surprises from naive misuses like "chmod -r file".
   POSIX allows diagnostics here, as portable code is supposed to use
   "chmod -- -r file". */
static bool diagnose_surprises;

Changing the testcase to "chmod -- -x testfile" makes the exit code and warning go away.

This is certainly an incompatible change in behaviour if so, though it wouldn't be the first.

Of course, if it's deciding that I'm on crack and should be ignored, surely it should never call chmod(2) in the first place?

At any rate, the behavior is POSIX-mandated. POSIX also has the note: "Some implementations of chmod never used the process' umask when changing modes; systems conformant with this volume of IEEE Std 1003.1-2001 do so when who is not specified."

Are we okay to close this bug out, then? (I don't feel confident to reject Zimmerman bugs ;) )

While this change is confusing, it's apparently conformant, and both chmod a-x and chmod -- -x do the expected thing. I'll retrain my fingers. (rejecting)