From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 1005D38582B7 for ; Wed, 13 Jul 2022 12:57:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1005D38582B7 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-157-1_3sBdi7Me2jf3MBoUibTA-1; Wed, 13 Jul 2022 08:57:23 -0400 X-MC-Unique: 1_3sBdi7Me2jf3MBoUibTA-1 Received: by mail-qv1-f71.google.com with SMTP id q16-20020a0ce210000000b00472f361d6b1so3736051qvl.21 for ; Wed, 13 Jul 2022 05:57:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=S0EgIi6jKJfSg6679X/ONVyOJ8LWRNLin0+nNd0r3XQ=; b=pz9TyyRrQtRQdFup/aTBR224rF1tV5Ka8jeWq6N5D97HD7SokDsWE41m+UxPnxJqc3 cVJiQMVEnzjxU52S0PAmbzYvJhffHuVcNLNWwPJ/kK8xyIrXgh/SCHCZ10CE6H8JQHON MTaFxz33Jx+ei236RcOExof6xoBHBhJCObt/Yhk09F6twm5EN1Mh19gDAxL0nVPEfUgm qI13e/eKveVkj0Tl21sfghf9dlkNE8t0ML5RV3WDdUXt5MRTLr/yoOqW4bQdFojxhB/D RRUhR4IiUh8vUnyJVRPg/QcsIY+4+t7KqxkD3lp2eZO260MW2XWiloTsKsVDwgih0yHH /dxQ== X-Gm-Message-State: AJIora86/SKUtElptLJpgAyG2pL+ELdqP/0+yyAqM/jjOXg4671JO8jZ v02Q+8idrNZ5HGq2UYuTg49PiEflXy9DTZcWD6RqgZ3auPX3YBF9q3GL7vtNATJG8g6Wa+ARblh 2oYZLk+Y= X-Received: by 2002:a05:6214:20a2:b0:473:691d:e4ce with SMTP id 2-20020a05621420a200b00473691de4cemr2624215qvd.90.1657717043156; Wed, 13 Jul 2022 05:57:23 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s/czqXwSvV6elXtEFc0mgo50kklSHqC+gtFkMckdFEDksaFapYUaHDxAi32qtwHVS0U7LzzA== X-Received: by 2002:a05:6214:20a2:b0:473:691d:e4ce with SMTP id 2-20020a05621420a200b00473691de4cemr2624205qvd.90.1657717042956; Wed, 13 Jul 2022 05:57:22 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id l20-20020a05622a175400b00304fa21762csm6597141qtk.53.2022.07.13.05.57.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 05:57:22 -0700 (PDT) Message-ID: Subject: Re: Adding file descriptor attribute(s) to gcc and glibc From: David Malcolm To: Szabolcs Nagy Cc: Mir Immad , gcc@gcc.gnu.org, libc-alpha@sourceware.org Date: Wed, 13 Jul 2022 08:57:20 -0400 In-Reply-To: References: <260f0b41c663133cea96eb64bd85e8ba16d8a936.camel@redhat.com> <5769682d0d17579cbd72f72a4001bfa8444b80a8.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 12:57:27 -0000 On Wed, 2022-07-13 at 09:37 +0100, Szabolcs Nagy wrote: > The 07/12/2022 18:25, David Malcolm via Libc-alpha wrote: > > On Tue, 2022-07-12 at 18:16 -0400, David Malcolm wrote: > > > On Tue, 2022-07-12 at 23:03 +0530, Mir Immad wrote: > > > GCC's attribute syntax here: > > >   https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html > > > allows for a parenthesized list of parameters for the attribute, > > > which > > > can be: > > >  (a) An identifier > > >  (b) An identifier followed by a comma and a non-empty comma- > > > separated > > > list of expressions > > >  (c) A possibly empty comma-separated list of expressions > > > > > > I'd hoped to have an argument number, with an optional extra param > > > describing the direction of the access, but syntax (b) puts the > > > identifier first, alas. > > > > > > Here's one possible way of doing it with a single attribute, via > > > syntax > > > (b): > > > e.g. > > >    __attribute__((fd_argument (access, 1)) > > >    __attribute__((fd_argument (read, 1)) > > >    __attribute__((fd_argument (write, 1)) > > > > > > meaning that argument 1 of the function is expected to be an open > > > file- > > > descriptor, and that it must be possible to read from/write to that > > > fd > > > for cases 2 and 3. > > > > > > Here are some possible examples of how glibc might use this syntax: > > > > > >     int dup (int oldfd) > > >       __attribute((fd_argument (access, 1)); > > > > > >     int ftruncate (int fd, off_t length) > > >       __attribute((fd_argument (access, 1)); > > > > > >     ssize_t pread(int fd, void *buf, size_t count, off_t offset) > > >       __attribute((fd_argument (read, 1)); > > > > > >     ssize_t pwrite(int fd, const void *buf, size_t count,  > > >                    off_t offset); > > >       __attribute((fd_argument (write, 1)); > > > > > > ...but as I said, I'm most interested in input from glibc > > > developers on > > > this. > > note that glibc headers have to be namespace clean so it > would be more like > >   __attribute__((__fd_argument (__access, 1))) >   __attribute__((__fd_argument (__read, 1))) >   __attribute__((__fd_argument (__write, 1))) > > so it would be even shorter to write > >   __attribute__((__fd_argument_access (1))) >   __attribute__((__fd_argument_read (1))) >   __attribute__((__fd_argument_write (1))) As I understand it, you'd use a macro for this, but this made me think of the following attributes that GCC could provide: __attribute__ ((fd_arg(N))) __attribute__ ((fd_arg_read(N))) __attribute__ ((fd_arg_write(N))) (since GCC already has "__attribute__((format_arg(N)))") It looks like you define your attribute macros in: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=misc/sys/cdefs.h;hb=HEAD which presumably could be extended to add something like: #if __GNUC_PREREQ (13, 0) # define __attr_fd_arg(argno) __attribute__ ((fd_arg(argno))) # define __attr_fd_arg_read(argno) __attribute__ ((fd_arg_read(argno))) # define __attr_fd_arg_write(argno) __attribute__ ((fd_arg_write(argno))) #else # define __attr_fd_arg(argno) # define __attr_fd_arg_read(argno) # define __attr_fd_arg_write(argno) #endif if I've got my syntax correct. (Or maybe "readable" and "writable"?) > > I just realized that the attribute could accept both the single integer > argument number (syntax (c)) for the "don't care about access > direction" case, or the ({read|write}, N) of syntax (b) above, giving > e.g.: > >     int dup (int oldfd) >       __attribute((fd_argument (1)); > >     int ftruncate (int fd, off_t length) >       __attribute((fd_argument (1)); > >     ssize_t pread(int fd, void *buf, size_t count, off_t offset) >       __attribute((fd_argument (read, 1)); > >     ssize_t pwrite(int fd, const void *buf, size_t count, >                    off_t offset); >       __attribute((fd_argument (write, 1)); > > for the above examples. > > How does that look? > Dave i think fd in ftruncate should be open for writing. Agreed. So with the above macros, this might look like: int dup (int oldfd) __attr_fd_arg(1); int ftruncate (int fd, off_t length) __attr_fd_arg_write(1); ssize_t pread(int fd, void *buf, size_t count, off_t offset) __attr_fd_arg_read(1); ssize_t pwrite(int fd, const void *buf, size_t count, off_t offset); __attr_fd_arg_write(1); to be honest, i'd expect interesting fd bugs to be dynamic and not easy to statically analyze. the use-after-unchecked-open maybe useful. i would not expect the access direction to catch many bugs. One goal of -fanalyzer is to help detect problems as code is written, before it ever leaves the developer's workstation. So for instance it might save a few seconds helping catch silly bugs where a developer is working with two different FDs and gets the read and write FDs the wrong way around. Dave