From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by sourceware.org (Postfix) with ESMTPS id 443AC38618B2 for ; Fri, 18 Dec 2020 16:56:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 443AC38618B2 Received: by mail-qt1-x829.google.com with SMTP id a6so1721158qtw.6 for ; Fri, 18 Dec 2020 08:56:40 -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=kmOvW7GU6XD9OPZ7672fVi1DDcqMnprvboHjP+IRyu0=; b=NeHw1M9/lbZ3XqA5IfMsr3i7Esk3thbMfAEuGp/a9hJBMjvWgQRIOK4sgtjWq1e3vZ MaWC7nlJoWTT3pMhQmKzHVxp/x9jNyOSKfmKnrf0P5qxSkIFHVKHlFyWizVsqXvV1hgS CdIK3RSnUrTREfmMyYtDwWdeqF4N01iGSghquYT6ULcWY4jMkHNz4EIgZ0pq9vv6eYYs lcttUkxy7e8LGIrb7CrjGXwU9irzxKZUNyDcbxqOydUesQMKXAOpEJvWq6jEkhoQpfCC F2DHNQhsKh2/IbXTJlQylMGet0N0lQItpL/jSE3FgTl/8Iy7MVHNsI+sGYiVZvSOSZky akzg== X-Gm-Message-State: AOAM5329SEMQzzRYKOKSp3QcrpaMQshocFyO59RbvnvxXVAAPOO/6dZY TOyQkUbsyJAFSuzsltNrbEtaSOHoEbU= X-Google-Smtp-Source: ABdhPJy0MmewKkkMwm5G8VHNzuUVPaMURjhxQiu8+CJ0sv1yPbNbuL361ShcmvASFozKM3cR7czPjA== X-Received: by 2002:ac8:4705:: with SMTP id f5mr2485599qtp.37.1608310599649; Fri, 18 Dec 2020 08:56:39 -0800 (PST) Received: from [192.168.0.41] (174-16-97-231.hlrn.qwest.net. [174.16.97.231]) by smtp.gmail.com with ESMTPSA id s67sm5297634qkh.101.2020.12.18.08.56.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Dec 2020 08:56:39 -0800 (PST) Subject: Ping: [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: Date: Fri, 18 Dec 2020 09:56:33 -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=-0.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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: Fri, 18 Dec 2020 16:56:41 -0000 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.