From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 9ED8A3858C2C for ; Fri, 15 Apr 2022 19:27:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9ED8A3858C2C Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-deb9295679so8818282fac.6 for ; Fri, 15 Apr 2022 12:27:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M2QyPEjkeiCX6+MYj42t4MloiT5B0XvqPozGBXuLcyQ=; b=LKMSbSkfjMRqrz3/XM+OuPRiCF0AcMuSQ+uijdfU1hs1+H+xnSVpvQIcabHkKQM8WN a3Zn4PBkMJRcJVv6+syAAmNMqjO8mTwnOpe8vTdzeuttJ3tRqql/BrK3nG3c/kS448eX VXY5pVfs4tLRP/USwDLbYtSaFniijdZghaorMjsd2E7WTYmMXaysVtgD3s9t2e9c1h+7 XYBsKnfEvZlTYs5Vhb1uereiqB8BcLZ7nOSJOYnhGpt/59sqps6bBUQYWDVpkYP/2yRi Q0LZXEDw2+jeB2zYQ6sGgqcXXeyfol50z2egmy5NwVFqnwE8eNx9aYOkIbozHL6WL4UX UQ0g== X-Gm-Message-State: AOAM532QgRSc+y0lUIz4K+pdS5E1d7tXB8JUurR0WQHe6b4quXjeV4bS HQav3Lo0mSkgFsggGirQUZqkTHDBcs0KvoVodFQA2PiClDw= X-Google-Smtp-Source: ABdhPJxlfP8t8ZTVW+fUrQYQSW5dF7U7isfWRcbfK5XohzlrzGS+Fsn6uCxkp86whq73GecH9CSgTdODjc83yu7CkBI= X-Received: by 2002:a05:6870:240a:b0:de:7fcb:56c0 with SMTP id n10-20020a056870240a00b000de7fcb56c0mr212718oap.8.1650050858615; Fri, 15 Apr 2022 12:27:38 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?zqbPjs+EzrfPgiDOks6xzrvOsc+DzrnOrM60zrfPgg==?= Date: Fri, 15 Apr 2022 22:27:27 +0300 Message-ID: Subject: GSoC thoughts on C++ static analyzer support To: gcc@gcc.gnu.org X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Fri, 15 Apr 2022 19:27:41 -0000 Hello all, I am interested in said project, and I'd like to ask. Is said project limited to providing static analysis for heap allocations and file handles? To be clear I am asking whether or not there are goals beyond these two. This pattern could pretty much be used for all resource-like objects such as sockets, mutexes et cetera and point is that said problems in C++ are already tackled by using RAII . Now I understand that RAII isn't always an option nor does it solve all problems (for example, dangling references) so I am still fascinated by all of it and would like to share my thoughts. C++11 mutexes(locks, and generally speaking all thread header facilities) could really use a static analyzer. Not only for the standard lock(), unlock() checks but also for "enforcing" lock ordering and other important guidelines. Read Anthony William's "Concurrency in Action" a while ago and honestly if I had a compiler that performed all those checks he describes in the book for me, which half of them I don't even remember anymore, THAT would be something else. Now I understand that this might be really complicated for a GSoC project, but food for thought. Looking forward to hearing your thoughts on this. Thanks for your time!