[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241105051505.GG10433@brightrain.aerifal.cx>
Date: Tue, 5 Nov 2024 00:15:05 -0500
From: Rich Felker <dalias@...c.org>
To: lihua.zhao.cn@...driver.com
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2] mman: correct length check in __shm_mapname
On Tue, Nov 05, 2024 at 12:56:28PM +0800, lihua.zhao.cn@...driver.com wrote:
> From: Lihua Zhao <lihua.zhao.cn@...driver.com>
>
> account for leading slashes when comparing against NAME_MAX.
>
> Signed-off-by: Lihua Zhao <lihua.zhao.cn@...driver.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
