You do not check for invalid tail of the text, so for instance 10XXX is parsed as 10. Is this intended?

May be take a look at expand_number(). I am not saying that it must be used, but at least it could be evaluated.

I do not think this is good check. You need to ensure that no bits outside 0x666 (perhaps expressed by S_I* constants) are set.

Why doing such trip through errno? warn(3) already formats with errno, then I do not see much use of translating each errno value into specific exit code. More, that contradicts Unix tradition of typically returning 1 if there is runtime error, and 2 if there is a bad parameter/config. Then you could just set the exit code locally.

How is it possible? If the queue was opened successfully, fd must be valid.

I am not sure why not apply the mode always. Anyway, the check should use symbolic
constant like S_IRWXU | S_IRWXG | S_IRWXO.

There is something wrong with indent.

No need to cast

Good question. parse_long is for queue depth and message size. The parse_unsigned below is for UID / GID.

3.437 User Name
A string that is used to identify a user; see also User Database. To be portable across systems conforming to POSIX.1-2017, the value is composed of characters from the portable filename character set. The <hyphen-minus> character should not be used as the first character of a portable user name.

If any non-numeric characters appear, I should treat it as a group or user name. However, the parse_group and parse_user functions have already consulted getpwnam / getgrnam before calling parse_unsigned so it can simply fail, leaving the corresponding boolean flag false.

Thanks @kib!

See parse_mode. The ranges are enforced there.

When mqueuefs related stuff fails, it is sometimes due to the mqueuefs kernel module was not loaded. This is very different from no-such-queue-name or user-not-permitted. The different exit codes help. The person staring at the keyboard can see the text and the script that invoked the utility can capture the exit code. Both have an equal chance of understanding the error.

My reason for different exit codes comes from unpleasant experiences in production where something failed with no clear explanation as to why. I've adopted the opinion that the worst kind of error is the "something bad happened" message (or exit code). Exit code '1' is an example of this.

I'd like to confirm this. It would be useful info for the document bug related to mq_getfd_np.

I found out recently that setting the S_ISUID or S_ISGID bits is only possible from mq_open. fchmod ignores them on mqueuefs. If I applied always, those bits would be cleared.

I do not know if setting those bits has any value for mqueuefs.

I'll update the code to use the IS_XXXXX bit masks.

Thanks @kib. That's 30+ years of C++ sneaking through. Your patience is appreciated.

Note that this comment is for a function that was removed.

@kib - if you can confirm this is safe behavior, I can update the code here and also the proposed manual page attached to bug https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273230

I missed this (again). One more pass coming.

Side note: the largest mqueuefs message size is 32768. Maximum number of queues is 64. Unknown on maximum queue depth.

Typo.

Also, what do you mean by "message depth"? mq_open(2) has no mention of that, but mentions a maximum number of messages. Is that what you mean? If so, maybe "queue size" as I suggested below?

I would move this paragraph to the DESCRIPTION section and rename the SUMMARY section to NOTES.

Avoids "you".

Also, what do you mean by "message depth"?

My intent was "queue depth".

My personal opinion is the word "size" is overloaded. On a mounted mqueuefs, typing 'cat /queue-name' returns the queue size - which is the sum of the length of all messages and MSGSIZE which is maximum size of any individual message. I prefer depth to refer to "number of messages" so that you can have "current queue depth" and "maximum queue depth". I understand this doesn't align with POSIX terminology.

Disclaimer: I've work with IBM MQs since 2005 - where "depth" is the prevailing term.

A quick survey of other message queues (RabbitMQ, MQTT, Kafka) shows "queue size" as the most prevalent.

Let me see what I can do here.

It is definitely not.