From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 1677C3861896 for ; Mon, 4 Jan 2021 15:54:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1677C3861896 Received: by mail-ot1-x32f.google.com with SMTP id r9so26369267otk.11 for ; Mon, 04 Jan 2021 07:54:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lOrHcuNZcymHykt/V0oxCkvexRukbr1PgHgiQMdxbvw=; b=AEr9PF4vhtrna4WOWDLc9dJ2aP8p/8NW2P6aF2Sj1xru8qdF73/PpZZDsGtrYtl0pu lWo9GdB7NwtC/wusC6r9w0I/b84uhivpe9X4x8fhPIJCLYTmKzguhTabWPJl+T+YNaw5 uGW+2Dprp1dolUq2FLVC0ecYk2HCe59XkAZ1OEkNr5a4SfWKdp7ZR94r+c82b4dQwZlA JLFFzjoA9O4qSMZ+v87TNL7snts6+gpCfSM/StgTmmdZg/XdGYwkHKKYiwfQiL0vYCfq hcrRdKP7H7O8aZs7h7lc7jaXTxB3hyHGV91lsU/9k/2LUL/6N2y+I3+P4q+Y3Hp8qNnk watg== X-Gm-Message-State: AOAM530Li5B2QK2AL167KcM0MlZvzK7XIiaYnRHU6Uw+M8DTYuHJ74Tn xm75RO9QjUXrm70bzL8v8jgv1dpm90A= X-Google-Smtp-Source: ABdhPJzt47P6dN274q3/+kB5kSWXJAHA/uwsWOf0FwdbcbrrpmgsNK4KdA+9qBBMvqWHvN9TzSdExw== X-Received: by 2002:a05:6830:1553:: with SMTP id l19mr52405462otp.335.1609775649128; Mon, 04 Jan 2021 07:54:09 -0800 (PST) Received: from [192.168.0.41] (75-166-96-128.hlrn.qwest.net. [75.166.96.128]) by smtp.gmail.com with ESMTPSA id o49sm13431441ota.51.2021.01.04.07.54.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jan 2021 07:54:08 -0800 (PST) Subject: Ping 2: [PATCH] more out of bounds checking improvements From: Martin Sebor To: Joseph Myers Cc: GNU C Library References: <176ba75f-4299-073f-8319-66dbf9fe3f42@gmail.com> Message-ID: <62e88e46-112f-b5e3-81a5-82732bd8cc28@gmail.com> Date: Mon, 4 Jan 2021 08:54:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 04 Jan 2021 15:54:11 -0000 Joseph or anyone else: is the patch below okay to commit? I'd like to include it in the upcoming release. https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html On 12/18/20 9:56 AM, Martin Sebor wrote: > Ping: Does the last patch look good enough to commit? > https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html > > On 12/9/20 2:46 PM, Martin Sebor wrote: >> On 10/26/20 10:08 AM, Joseph Myers wrote: >>> 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). >> >> I don't know enough about the Glibc build infrastructure to >> understand your suggestion but either approach sounds more involved >> than I have cycles for so I propose the scaled patch instead, without >> the ctermid and cuserid changes (and without the nonnull attribute >> on readv/writev(*)).  Hopefully someone with more experience with >> the existing scheme will find a way to define the two macros and >> make use of them to enable the detection for these two functions >> as well. >> >> Martin >> >> [*] I'll submit that patch separately. >