`mq_open` panic when using nix

[tight escarp]

I am trying to compile the example from nix's mqueue module and it is panicking on mq_open with EINVAL.
I have re-implemented this code in C and it worked perfectly and moreover, once the message queue was formed this code no longer panicked and ran just fine. If I manually created the file in /dev/mqueue/ it was happy. I used the same flags and everything in the C version and that ran with no problems at all.

This has been driving me crazy enough I even went back and tried it on an older distro, Rocky Linux 9 *spits*, and it had the exact same result. So far I have tried this on latest Debian, RL9, and NixOS unstable.

Here is my code straight from the example with the fs and mqueue features active:

use nix::mqueue::{mq_attr_member_t, mq_close, mq_open, mq_receive, mq_send, MQ_OFlag};
use nix::sys::stat::Mode;
fn main() {
    const MSG_SIZE: mq_attr_member_t = 32;
    let mq_name = "/a_nix_test_queue";

    let oflag0 = MQ_OFlag::O_CREAT | MQ_OFlag::O_WRONLY;
    let mode = Mode::S_IWUSR | Mode::S_IRUSR | Mode::S_IRGRP | Mode::S_IROTH;
    let mqd0 = mq_open(mq_name, oflag0, mode, None).unwrap();
    let msg_to_send = b"msg_1";
    mq_send(&mqd0, msg_to_send, 1).unwrap();

    let oflag1 = MQ_OFlag::O_CREAT | MQ_OFlag::O_RDONLY;
    let mqd1 = mq_open(mq_name, oflag1, mode, None).unwrap();
    let mut buf = [0u8; 32];
    let mut prio = 0u32;
    let len = mq_receive(&mqd1, &mut buf, &mut prio).unwrap();
    assert_eq!(prio, 1);
    assert_eq!(msg_to_send, &buf[0..len]);

    mq_close(mqd1).unwrap();
    mq_close(mqd0).unwrap();
}

Here is the backtrace

thread 'main' panicked at src/main.rs:9:53:
called `Result::unwrap()` on an `Err` value: EINVAL
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library/std/src/panicking.rs:647:5
   1: core::panicking::panic_fmt
             at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library/core/src/panicking.rs:72:14
   2: core::result::unwrap_failed
             at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library/core/src/result.rs:1649:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library/core/src/result.rs:1073:23
   4: mqueue_test::main
             at ./src/main.rs:9:16
   5: core::ops::function::FnOnce::call_once
             at /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

This makes me think it might be a problem with their implementation of with_nix_path which can also return a EINVAL here but frankly I do not know

If anyone has the time to boot this up real quick I would appreciate knowing I am not losing it

[keen hill]

"/" is generally not read/write permissioned in nixos, try picking a permissioned location.

[tight escarp]

This is not a NixOS package, it is for *nix sys calls. This problem has presented on Debian and Rocky Linux 9

[keen hill]

I would still reason root permissioning issue true on most linux distros.

[tight escarp]

Names for message queues must start with a slash. It is not a file path
Please read this: https://man7.org/linux/man-pages/man7/mq_overview.7.html

[keen hill]

Totally fair, my bad for improper assumptions, after reading that doc EINVAL for mq_open means name doesn't follow the format in mq_overview(7).

And rust str slices are not null terminated which is a requirement

Does the rust library automatically add these terminations?