Re: [musl] [PATCH v2] mman: correct length check in __shm_mapname

[Rich Felker <dalias@libc.org>]

On Tue, Nov 05, 2024 at 12:56:28PM +0800, lihua.zhao.cn@windriver.com wrote:
> From: Lihua Zhao <lihua.zhao.cn@windriver.com>
> 
> account for leading slashes when comparing against NAME_MAX.
> 
> Signed-off-by: Lihua Zhao <lihua.zhao.cn@windriver.com>
> ---

I'm still not clear what you're trying to achieve here. If the bug is
"it's different from glibc", that is not a bug.

> According to https://pubs.opengroup.org/onlinepubs/9799919799/:
> 
> leading <slash> character in name is implementation-defined, and
> that the length limits for the name argument are
> implementation-defined and need not be the same as the pathname
> limits {PATH_MAX} and {NAME_MAX}.
> 
> Although it is implementation-defined, glibc obviously calculates the lead slash.

Leading slash is not implementation-defined. The text you quoted says
the opposite if you didn't cut off the earlier part of the sentence:

"...except that the interpretation of <slash> characters other than
the"

A leading slash is necessary to portably open shared memory by a name
in a shared global namespace. Omitting it, or using slashes elsewhere
in the name, is what's implementation-defined.

Indeed the limits need not match NAME_MAX, but since we implement
named shared memory objects as filesystem objects, the implementation
choice we make is to have the limit match.

Rich