From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27556 invoked by alias); 27 Nov 2017 16:25:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 26762 invoked by uid 89); 27 Nov 2017 16:25:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=UD:gmane.org, HTo:U*carlos, UNIX X-HELO: mail-oi0-f65.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zNnJDXyHKDXjNLFOiMc++5nlSYOHU1xaofvlrI/CoJw=; b=o3YgsRaAE23820riUYgB4mqsaqNTNwrrR2H0hkj4GJ/qGtBLbVmKg6pS7N6JQfobea JnHdt/Ltci+P3342GhlE6jFfKAxO3FdNQS4FOta7uy2td2uNGlw/sOJy4nsJEKzDIn9M lN6UPpbDm3qFTStJn+nI495FoXcOWpQtzOH8EBtOQMed8LdLkcgD2hTODgtbf6XqI0Dc KNyGyMpdvEbf7JHwbFpFSvtSK1RnFjWWCqGiv0n70BWapdlqLIxitve2AnvvjEPQmxDn IKvmJXTgYYyK/99STMelbdXLkVJTJMz2XWeEZcxrRyq06HNKh6iEvkbrL1ZTclR3WZ1d oT6g== X-Gm-Message-State: AJaThX4j84UMfWXQLdTr7oh0tqanZh+UL+8Uq7CPeLXQRpS5jjXAyGRT eyWG1R79mvD4TnQgT9IglWNTpA== X-Google-Smtp-Source: AGs4zMb0Z0x9FteqSto/04tOrqkIXYwBSWg5GFJRPMAFjFlY5dEzx2tcpoEGortMm6geN4nEOqK51A== X-Received: by 10.202.49.6 with SMTP id x6mr15060363oix.338.1511799900003; Mon, 27 Nov 2017 08:25:00 -0800 (PST) From: Martin Sebor Subject: Re: nonstrings in Glibc To: Carlos O'Donell , GNU C Library References: <797b60f7-1bd0-2b05-c25b-385ea3b04e68@redhat.com> <2d1095ea-a158-f3ff-2cc4-006dea8387e6@gmail.com> <20171122001425.GA5120@altlinux.org> Message-ID: <891f8f0b-75e4-8273-4d6b-eed70dd2d616@gmail.com> Date: Mon, 27 Nov 2017 16:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171122001425.GA5120@altlinux.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-11/txt/msg00928.txt.bz2 On 11/21/2017 05:14 PM, Dmitry V. Levin wrote: > On Tue, Nov 21, 2017 at 04:41:27PM -0700, Martin Sebor wrote: >> On 11/20/2017 11:20 AM, Carlos O'Donell wrote: >>> On 11/20/2017 08:54 AM, Martin Sebor wrote: >>>> I'm done testing my update to the -Wstringop-truncation GCC patch >>>> to find misuses of non-string arrays. With the very limited use >>>> of attribute nonstring it only found one potential bug (22447). >>>> I've been looking at other uses of strncpy in Glibc to see if there >>>> are other arrays that would benefit from the attribute. I'm not >>>> sufficiently familiar with Glibc data structures so it's a very >>>> slow going. Could someone help suggests data structures with >>>> array members that might be candidates? >>> >>> struct sockaddr's sun_path? >>> >>> http://thread.gmane.org/gmane.comp.standards.posix.austin.general/5735 >>> >>> Is that what you need help finding? >> >> Yes, that's what I'm looking for, thanks! >> >> From the referenced thread it sounds like POSIX doesn't require >> sun_path to be nul-terminated and BSD UNIX doesn't terminate it. >> But I'm not sure what happens on Linux. According to Michael >> Kerrisk's response it sounds like it is nul-terminated, but >> then according to the longer discussion on linux.kernel.api >> it sounds like it isn't. Which is it? > > When struct sockaddr_un is passed to linux kernel, the kernel doesn't > treat sun_path as nul-terminated, see net/unix/af_unix.c:unix_mkname > for implementation details. Thank you. This is good to know (and expected). The Glibc attribute is meant to help with the user side of things so it's your note below that's especially relevant. (There are a few warnings in the Linux kernel suggesting it too might benefit from the new attribute, if only to suppress them.) > However, when linux kernel returns struct sockaddr_un, sun_path is > nul-terminated if there is enough room provided by userspace, e.g. > it may need sizeof(struct sockaddr_un) + 1 bytes to write that NUL > beyond struct sockaddr_un.sun_path. So if I understand correctly, sun_path will contain a nul- terminated string if there is enough room for the terminating nul but not otherwise. If that's so, that would suggest that adding attribute nonstring to sum_path might be appropriate. At the same time, based on existing usage it seems that it would be prone to false positives. Annotating sun_path with it turns up only one warning in a Glibc build: clnt_unix.c:137:13: warning: ‘strlen’ argument 1 declared attribute ‘nonstring’ [-Wstringop-overflow=] len = strlen (raddr->sun_path) + sizeof (raddr->sun_family) + 1; AFAICS, the function is only called from clnt_create() where it's passed a nul-terminated string, so unless it can be called from user code with a non-nul-terminated array this would be an example of such a false positive. Carlos, do you think the attribute would be helpful despite the false positives? Martin