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

["Zhao, Lihua (CN)" <Lihua.Zhao.CN@windriver.com>]

Thank you for your support and respect your decision. Anyway, this is just a boundary management and is usually not used, so it is OK not to change it.

Lihua

-----Original Message-----
From: Rich Felker <dalias@libc.org> 
Sent: Tuesday, November 5, 2024 1:15 PM
To: Zhao, Lihua (CN) <Lihua.Zhao.CN@windriver.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] [PATCH v2] mman: correct length check in __shm_mapname

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

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