From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 83FB723F2D for ; Tue, 5 Nov 2024 06:15:20 +0100 (CET) Received: (qmail 13427 invoked by uid 550); 5 Nov 2024 05:15:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com x-ms-reactions: disallow Received: (qmail 13393 invoked from network); 5 Nov 2024 05:15:16 -0000 Date: Tue, 5 Nov 2024 00:15:05 -0500 From: Rich Felker To: lihua.zhao.cn@windriver.com Cc: musl@lists.openwall.com Message-ID: <20241105051505.GG10433@brightrain.aerifal.cx> References: <20241105030058.GF10433@brightrain.aerifal.cx> <20241105045628.1542264-1-lihua.zhao.cn@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241105045628.1542264-1-lihua.zhao.cn@windriver.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [PATCH v2] mman: correct length check in __shm_mapname On Tue, Nov 05, 2024 at 12:56:28PM +0800, lihua.zhao.cn@windriver.com wrote: > From: Lihua Zhao > > account for leading slashes when comparing against NAME_MAX. > > Signed-off-by: Lihua Zhao > --- 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 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 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