From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28719 invoked from network); 27 Apr 2021 19:56:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Apr 2021 19:56:10 -0000 Received: (qmail 25924 invoked by uid 550); 27 Apr 2021 19:56:03 -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 Received: (qmail 25888 invoked from network); 27 Apr 2021 19:56:03 -0000 Date: Tue, 27 Apr 2021 21:55:50 +0200 From: Szabolcs Nagy To: Matus Kysel Cc: musl@lists.openwall.com Message-ID: <20210427195550.GK2799122@port70.net> Mail-Followup-To: Matus Kysel , musl@lists.openwall.com References: <611bff39248143248ce9edd6762fb804@tachyum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <611bff39248143248ce9edd6762fb804@tachyum.com> Subject: [musl] Re: libc-test issue with sem_close * Matus Kysel [2021-04-26 09:49:35 +0000]: > Hi Szabolcs, > > I am using your library as part of my validation suite and recently I have updated it to latest master, but the sem_close test is not buildable for me as it is missing fcntl.h header. I have attached possible fix, because I did not found how to contribute to you repo. ccing musl, libc-test is mostly discussed there. posix says "Inclusion of the header may make visible symbols defined in the and headers." https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/semaphore.h.html which sounds optional, not guaranteed visibility of O_ open flags in semaphore.h, but sem_open is expected to be usable with only semaphore.h https://pubs.opengroup.org/onlinepubs/9699919799/functions/sem_open.html i'm not sure what is the strict standard requirement here, without clarification i consider it a libc header issue if an api is not usable with just the header where it is declared.