print_numeric: print mode in octal when the mode is too large

[Connor-GH]

No description provided.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/shuf/shuf-reservoir (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/sort/sort-stale-thread-mem (passes in this run but fails in the 'main' branch)

[sylvestre]

could you please add a test to make sure we don't regress in the future? thanks

[ChrisDryden]

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

[Connor-GH]

Heres an example test for this scenario for chmod that you can use in test_chmod:

#[test]
fn test_chmod_mode_too_large_error_shows_octal() {
    let scene = TestScenario::new(util_name!());
    let at = &scene.fixtures;
    at.touch("file");

    scene
        .ucmd()
        .arg("10777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (10777 > 7777)");

    scene
        .ucmd()
        .arg("77777")
        .arg("file")
        .fails()
        .stderr_contains("mode is too large (77777 > 7777)");
}

I had something similar, I have just been really busy. I am a university student.

[Connor-GH]

The test case results in this:

running 1 test
test test_chmod::test_chmod_permissions_too_large ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 4097 filtered out; finished in 0.01s

[codspeed-hq]

CodSpeed Performance Report

Merging this PR will improve performance by 4.01%

_{Comparing Connor-GH:print_numeric-fix (7913280) with main (fe748f4)}

Summary

⚡ 1 improved benchmark
✅ 281 untouched benchmarks
⏩ 38 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Memory	numfmt_large_numbers_si[10000]	4.9 MB	4.7 MB	+4.01%

Footnotes

1. 38 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Connor-GH]

So the OpenBSD CI is failing because 7777 is considered to be in invalid value:

  thread 'test_chmod::test_chmod_permissions_too_large' panicked at tests/by-util/test_chmod.rs:310:45:
  Command was expected to succeed. code: 1
  stdout = 
   stderr = chmod: Inappropriate file type or format (os error 79)

Which is EFTYPE errno
This happens here in the OpenBSD code: https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/sys/ufs/ufs/ufs_vnops.c#L465

// <snip>
if (cred->cr_uid && !vnoperm(vp)) {
		if (vp->v_type != VDIR && (mode & S_ISTXT)) // S_ISTXT == 0o1000
			return (EFTYPE);
// <snip>

This gets triggered because:

1. we are not uid 0
2. !vnoperm(vp) passes
3. we are not a directory
4. we have S_ISTXT set because (0o7777 & 0o1000) == 0o1000.

They are aware of this, see https://github.com/openbsd/src/blob/8105fbd98be243a48cc198cd0c33d8bce8095608/regress/lib/libc/sys/t_mkfifo.c#L225-L229

[ChrisDryden]

My understanding is that the BSD error is only coming from this line, it should be okay to disable this specifically for BSD or do something like this:

// Use a directory for 7777 test since sticky bit (0o1000) on files requires root on BSD systems
at.mkdir("dir");
scenario.ucmd().args(&["7777", "dir"]).succeeds();