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.133.124]) by sourceware.org (Postfix) with ESMTPS id ADA0F382C149 for ; Wed, 13 Jul 2022 19:29:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADA0F382C149 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-656-AI59maFKPXerw9R3wjyt-g-1; Wed, 13 Jul 2022 15:29:21 -0400 X-MC-Unique: AI59maFKPXerw9R3wjyt-g-1 Received: by mail-qt1-f199.google.com with SMTP id x10-20020ac8120a000000b0031ea260a047so9796497qti.6 for ; Wed, 13 Jul 2022 12:29:21 -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=hYHOUpwayCopJGEPmHVvkYsZuS4zU7F1+S4rkXh1Drk=; b=dvM5uMPeQQ+lc15dFhsdkg+Us1xWBYqaqvatdqPZRf0Of0i1uBoj2MWmXtBEQJyvHZ yFR8adp6tYSG9qcPI7hBmzGSzZH3SyXE62DM9cx6MerqzT5xatkTjpHt7Pgw6nmRLMZQ VqJ+JlkCUNZkQ1ZKUD1u7s6td0734WDfFW4Kgy5InEBgszjWSsxJMHKbhEu+/OWJUxrx 6eSsH/EekD2ZgVP2EPhXPnYFh/fnoRB6khn9XZUpiKxDuonI0vMO73V9hxLuUwSEG1TO eX1K1etWV/MXttWRZ7gsPF5qSVaArtL2sgrS1j0u6vxxLoJ0LDDFVc8+9fXDtn7LY1zn kmxQ== X-Gm-Message-State: AJIora9KxLZe1a2TQG96Qwq9HJDNBYi4WCq6AUv76Nqkhqogg2WkrwxZ uRdPZQXf0a/Ciaxg3Tg+bVw1U2TBItAvWyhRJebJIDutyXbPM0melyEykZWaPuomiZqCYVU+Lo7 iHjC6Rks= X-Received: by 2002:a05:620a:2a10:b0:6b5:48f7:196 with SMTP id o16-20020a05620a2a1000b006b548f70196mr3563696qkp.529.1657740560764; Wed, 13 Jul 2022 12:29:20 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sQ1PIKdD5TYEEdencrAHn3ZAX0X/02981y0etdnDje+Mfs8riH/Ug2hoD/BSeheiq7G7bgMQ== X-Received: by 2002:a05:620a:2a10:b0:6b5:48f7:196 with SMTP id o16-20020a05620a2a1000b006b548f70196mr3563682qkp.529.1657740560556; Wed, 13 Jul 2022 12:29:20 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id bj18-20020a05620a191200b006a6ab8f761csm12852789qkb.62.2022.07.13.12.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 12:29:19 -0700 (PDT) Message-ID: <08c32347c4b433645875eb9ec283d72f915ab3d6.camel@redhat.com> Subject: Re: Adding file descriptor attribute(s) to gcc and glibc From: David Malcolm To: Mir Immad , Florian Weimer Cc: Szabolcs Nagy via Gcc , Szabolcs Nagy , libc-alpha@sourceware.org Date: Wed, 13 Jul 2022 15:29:18 -0400 In-Reply-To: References: <260f0b41c663133cea96eb64bd85e8ba16d8a936.camel@redhat.com> <5769682d0d17579cbd72f72a4001bfa8444b80a8.camel@redhat.com> <877d4h1alh.fsf@oldenburg.str.redhat.com> <6460438cc9e634d0b5e40a1438038c9adce151bb.camel@redhat.com> <87tu7lyuvv.fsf@oldenburg.str.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=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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 19:29:24 -0000 On Wed, 2022-07-13 at 22:26 +0530, Mir Immad wrote: > Hi everyone, > > Reading through the thread, I feel the following attributes look good > and > similar to what I've done: > > __attribute__ ((fd_arg(N))) > __attribute__ ((fd_arg_read(N))) > __attribute__ ((fd_arg_write(N))) > > I believe how to annotate the glibc headers is a separate discussion. > > Dave:  From the GCC side of things, these three attributes are basic > functionalities that can be useful for any piece of code that passes > around > file descriptors. Immad: sounds good. Please use the above names/syntax for the next iteration of your patch to -fanalyzer. Thanks! Dave > > Thanks > Immad > > > On Wed, Jul 13, 2022 at 7:31 PM Florian Weimer > wrote: > > > * David Malcolm: > > > > > On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote: > > > > * Szabolcs Nagy via Gcc: > > > > > > [adding Immad back to the CC list] > > > > > > > > > > > > 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. > > > > > > > > You might be right.  But I think the annotations could help to > > > > catch > > > > use-after-close errors. > > > > > > > > By the way, I think it would help us if we didn't have to > > > > special- > > > > case > > > > AT_FDCWD using inline wrappers. > > > > > > Florian: I confess I wasn't familiar with AT_FDCWD until I read > > > your > > > email and did a little reading a few minutes ago; it seems to be > > > a > > > "magic number" for an FD that has special meaning; on my system > > > it has > > > the value -100. > > > > > > GCC's current implementation of the various -Wanalyzer-fd-* > > > warnings > > > will track state for constant integer values as well as symbolic > > > values; it doesn't have any special meanings for specific integer > > > values.  So e.g. it doesn't assume that 0, 1, and 2 have specific > > > meaning or are opened with specific flags (the analysis doesn't > > > necessarily begin its execution path at the start of "main", so > > > there's > > > no guarantee that the standard FDs have their standard meaning). > > > > Ahh.  It might be useful to detect close (-1) etc. as a form of > > double-close, and ther AT_FDCWD is exceptional. > > > > > Presumably if someone attempts > > >   close (AT_FDCWD); > > > they'll get -1 and errno set to EBADFD, right? > > > > Correct > > > > > I don't think GCC's -fanalyzer needs to check for that. > > > > Not sure … > > > > > -fanalyzer's filedescriptor support doesn't yet have a concept of > > > "directory filedescriptors".  Should it?  (similarly, it doesn't > > > yet > > > know about sockets) > > > > > > A possible way to annotate "openat": > > > > > >   int openat(int dirfd, const char *pathname, int flags) > > >     __attr_fd_arg(1); > > > > openat is not the most general interface in this regard.  We have > > other > > *at functions which accept an O_PATH descriptor (or maybe even a > > different kind of non-directory descriptor) with pathname == "" and > > AT_EMPTY_PATH.  I'm not sure if modeling all this is beneficial. > > > > Thanks, > > Florian > > > >