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 738FA3858C55 for ; Sun, 3 Jul 2022 19:47:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 738FA3858C55 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-511-NqLqpJP8OxG2vSnsH72Bdw-1; Sun, 03 Jul 2022 15:47:15 -0400 X-MC-Unique: NqLqpJP8OxG2vSnsH72Bdw-1 Received: by mail-qk1-f197.google.com with SMTP id de4-20020a05620a370400b006a9711bd9f8so6904052qkb.9 for ; Sun, 03 Jul 2022 12:47:15 -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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=yBzvyuIKa7VqThPvyPAoSpAhiXEQtfv+530dUkF5IYw=; b=X+m4mNrXTichdENuDsvlXB5TCUO2SS/BL7qbH5gtaeWhcP3jCGVKMe/MPWXvo59xru 2yfBCxjUhOaH+HU2MxG0/tkA1brvJt1KVAm3pDaXd99cLkjutCcfjBxxe2XNOAoNP1Tu /Nekk4DU5kPwFvYMvOBXET5yzh2evyrPw0KqKSc46H6hBMkTsXbrEiOOTqkoP2JOzYlb HSeV73QUrlLz7CREFCBk6Blchtw1+Etyr/cgbNnFSxF0Ne3FHrV+N+n+1G+5xpRx9XGA qze+jN4DSOAMNDUb3kBljs0tmjbk5tF3Dde0OYw8q6wl8PQDyMm3vBtT+mvWfwWXvg8d DK4Q== X-Gm-Message-State: AJIora/zJciwHt/ntoDmQyvqc8CJspzU5qvwvuZW1nQu3Pic+lQj/1aO TRWahgb68LOTN7ovOOhp/NEj7MFdn0h3/3JV14veScALI/WA1esr7MkHtwwUKqPJQkS8Ex7BN2U 8qFGN+bk= X-Received: by 2002:a37:8a44:0:b0:6a6:3991:6f23 with SMTP id m65-20020a378a44000000b006a639916f23mr17102293qkd.762.1656877634243; Sun, 03 Jul 2022 12:47:14 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vW/kLct/Fw7c78uuhvhfpj16tROjXngAgwq3sPdXrH4qxUkpu5C1zoj10l/7IkdDOHp23Riw== X-Received: by 2002:a37:8a44:0:b0:6a6:3991:6f23 with SMTP id m65-20020a378a44000000b006a639916f23mr17102287qkd.762.1656877634008; Sun, 03 Jul 2022 12:47:14 -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 x7-20020ac81207000000b00304e4bbc369sm19192998qti.10.2022.07.03.12.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Jul 2022 12:47:13 -0700 (PDT) Message-ID: Subject: Re: analyzer: implement five new warnings for misuse of POSIX From: David Malcolm To: Jay K , gcc , "mirimmad17@gmail.com" Date: Sun, 03 Jul 2022 15:47:12 -0400 In-Reply-To: References: 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.6 required=5.0 tests=BAYES_00, 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: Sun, 03 Jul 2022 19:47:18 -0000 On Sun, 2022-07-03 at 02:46 +0000, Jay K wrote: >  > check for double "close" of a FD (CWE-1341). >  > check for read/write of a closed file descriptor >   >  These sound good but kinda non general or incomplete to me. >  I mean, isn't the "right" thing, to disallow passing >  a closed fd to "almost any" function?   > >  But I realize "almost any" is difficult to pin down. >   fd = open(); >   close(fd); >   printf("%d", fd);   > > is often ok (assuming nobody reads the output, string to int, > back to close/read/write). It is any path leading to, > a long list, like close, read, write, ioctl, send, recv, etc. > and I don't know if "path leading to" is possible to model here, > haven't looked, sorry. Jay: right now, the only function calls that these FD warnings know about are open, close, read, and write: the only "use" that -Wanalyzer- fd-use-after-close currently cares about is "read" and "write" (and double-close is its own diagnostic). I put together an example on Compiler Explorer here which tries to show as many of the new warnings as possible: https://godbolt.org/z/rsc51PYoK [1] I think we're going to want to add a new function attribute that signifies "this 'int' parameter is expected to be an open file descriptor" so that e.g. glibc's headers can use the attribute to mark up all the places expecting such FDs, and thus -fanalyzer can warn about misuses, lacking checks, etc. Probably some sort of support for dup, dup2, etc. Immad: we might want some test coverage that Jay's example doesn't generate a warning from -fanalyzer. Hope this makes sense Dave [1] I also put in a bounds-check bug in the first "write" call, which sadly we don't complain about yet. I've added a note about that to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000