From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3495E1FF9C for ; Mon, 26 Oct 2020 16:08:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 28E90393C874; Mon, 26 Oct 2020 16:08:33 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 67B133857813 for ; Mon, 26 Oct 2020 16:08:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 67B133857813 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: IurO4/oxdlJ6eE6Adj+9ugy3bVo2CslWLptd/1PMxOadT1/5tM2WTnEHFCVqH15wfs2sTyXrAz Y8Xss8y88+AsvDVbaDm8za7CWwALheTBTTsTo/HfzE+2yDrbaH5zOFhRio4G55Xjrta8Sab80I D7dujKwsO9GQzF2+7rey+CtJ6S1gjvHElzafMrDW0A8kMnsUz90j8Wwpl+NIV/9Lu/So/eYyRm rlCVHqGXnULCucgG09S4j7TrpMzVJxOWMjFQW/oPVdJN4kU8IavH6n5HXvOQQk+dRlpfN3y4Zh 9nQ= X-IronPort-AV: E=Sophos;i="5.77,420,1596528000"; d="scan'208";a="54403686" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 26 Oct 2020 08:08:29 -0800 IronPort-SDR: 1CDmmDlWXDDatmOk3ULATbZlO8eXYg6csvzTaiU3xz3TjU1Ei6myERZP9p9q6SkGWBesKy30Fz eTqnxx0vvWFjqCtrzPXf3md6ifrhNmOxPM1nUILdWptj8atZrbbY4B66hBetu4ktfoAlpzriFX Vjhqv6OsDfEkaFRr4mSJFljFhmCVQZlbCvhX+qZRgsuowdp9qtCxTNluhi8Ed6UMDO3rt/QvXZ Hk35uDrKG5s82qDiyKokv+qj03uNYOlJIVSxmDqZ8kuGOSJHfuJmu+3KrLvQWf7KYSCc2GcvCA xvw= Date: Mon, 26 Oct 2020 16:08:24 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Martin Sebor Subject: Re: [PATCH] more out of bounds checking improvements In-Reply-To: <176ba75f-4299-073f-8319-66dbf9fe3f42@gmail.com> Message-ID: References: <176ba75f-4299-073f-8319-66dbf9fe3f42@gmail.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Mon, 26 Oct 2020, Martin Sebor via Libc-alpha wrote: > The patch introduces the _L_tmpnam macro to avoid polluting > the POSIX namespace with L_tmpnam when the latter is > only supposed to be defined in . This in turn causes > the a number of POSIX conformance test failures that I haven't > been able to figure how to deal with and need some help with. > > In file included from ../include/unistd.h:2, > from /tmp/tmpzm39v4n3/test.c:1: > ../posix/unistd.h:1159:32: error: ‘_L_ctermid’ undeclared here (not in a > function) > extern char *ctermid (char __s[_L_ctermid]) __THROW > ^~~~~~~~~~ > > I expected adding the new macros to stdio-common/stdio_lim.h.in > would do the trick but clearly something else is needed and I'm > at a lost as to what that might be. I haven't been able to find doesn't include , and you're making use _L_ctermid, and you're only defining _L_ctermid in . You need to define it in a header that includes - which also needs to be one whose contents are namespace-clean for inclusion in (which isn't). The obvious way would be to have a new installed (i.e. add to "headers" in the relevant Makefile) header for the new macros that can be included in both and . Suggestion: the existing scheme for automatic generation of bits/stdio_lim.h is overly complicated, it would be better to use sysdeps headers in the normal way like for other bits/ headers where the values may depend on the glibc configuration (and then to have testcases that verify consistently of OPEN_MAX and FOPEN_MAX / of PATH_MAX and FILENAME_MAX, when both are defined). -- Joseph S. Myers joseph@codesourcery.com