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=-1.9 required=3.0 tests=BAYES_00,BODY_8BITS, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 6C6211F4B4 for ; Sun, 10 Jan 2021 20:44:36 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 87B503854835; Sun, 10 Jan 2021 20:44:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 87B503854835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610311475; bh=CserLp/mDzv7QKeoqF80evz1mKcTnObGkfdnC0V//fk=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=x1h9UVzBrCvRKbPQIoqVuoJh4czDIcNM5LAl8qsopIQNr9arvmZl3t/58N8PZbREh wBwqCt6/iXnAkL1iW1qrka/gE6aPRiTRCQ0ePMjtIAbqrxJ3lnYkzqwWzsqweXHH94 LclAaRIlZsYCL2JyzhCPUJImG3TzhN/9r599KfCo= Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by sourceware.org (Postfix) with ESMTPS id CE05A3857C67 for ; Sun, 10 Jan 2021 20:44:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CE05A3857C67 Received: by mail-io1-xd2b.google.com with SMTP id m23so15760728ioy.2 for ; Sun, 10 Jan 2021 12:44:32 -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=CserLp/mDzv7QKeoqF80evz1mKcTnObGkfdnC0V//fk=; b=mRn+9bvDUJbdTf86usLJ39c3LLDiI+ly0lx5pgt8gJqsTCE+hDNXkAODWLgO80+3hn HwLMNKCOfltIpSGXMh4IMG0FjzWGJkShJxZRg63O3r+pp4SQ4uiqYOLk1kLLU1ov3AyF 8lsi+3TCWE7xfn8fQ41YWXcR8CzPnORVRO3bPmjlLmB2gbqjXtjL7WypCSaE0fuO7nEw qAMCmq8cjt+VV5iestKMjR2BlVhtooQVE9dlFpw286BpKpg70IhZHBdUupTtONFkeVUe l8dFlVvNEq53j4tca3Np0otH7ZSIwRAeb3vwjixlPAIYYAeXxSeyJghJ6Gx2+Rf+9MTp IErA== X-Gm-Message-State: AOAM532OGVxQg7mnUiVNvl1cOIDrfX44bMQFUAYvx8fmY3vvQxUa+g2g I3BJcvszIBXdjM5J+kYcWo23FEwAzTo= X-Google-Smtp-Source: ABdhPJxgfB54cYBTq0CkuaWDaqI+kVIpftuXzdQjR9v5BxvUl7PlURmao89jyaTiXxRBipng5Z3J+w== X-Received: by 2002:a5e:d717:: with SMTP id v23mr12527744iom.60.1610311472156; Sun, 10 Jan 2021 12:44:32 -0800 (PST) Received: from [192.168.0.41] (184-96-239-30.hlrn.qwest.net. [184.96.239.30]) by smtp.gmail.com with ESMTPSA id e28sm9340061iov.38.2021.01.10.12.44.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Jan 2021 12:44:31 -0800 (PST) Subject: Ping 3: [PATCH] more out of bounds checking improvements To: Joseph Myers References: <176ba75f-4299-073f-8319-66dbf9fe3f42@gmail.com> <62e88e46-112f-b5e3-81a5-82732bd8cc28@gmail.com> Message-ID: <42c63456-4775-1c55-7e16-8fefa3275f56@gmail.com> Date: Sun, 10 Jan 2021 13:44:30 -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: <62e88e46-112f-b5e3-81a5-82732bd8cc28@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , From: Martin Sebor via Libc-alpha Reply-To: Martin Sebor Cc: GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Ping: still looking for an approval of the patch below before tomorrow's freeze: https://sourceware.org/pipermail/libc-alpha/2020-December/120586.html On 1/4/21 8:54 AM, Martin Sebor wrote: > 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. >> >