From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 17F8D70 for ; Mon, 26 Jul 2021 07:53:50 +0000 (UTC) Received: by mail-ua1-f49.google.com with SMTP id o10so3240038uaj.0 for ; Mon, 26 Jul 2021 00:53:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xJlphi2DJPiFMCSec4ZDlBNTGAOLhh1VY1qXF/r2VtM=; b=HjGtPB35L0lAfJ4FrgFDXYh8pACFGf5n17fbTXBDPf+U/Euk5dlcq68rK7EqlFl0YU YbBUsPl+7j4NGtw37wqfbAETYuhVU/8T9+orOlvkO+KMULSqT7RlQxY8A+iEwXBjP0Xe lve+gkLQzbIzvOMAYOm+X4o4g06IakHCV8/2+1NeUwX/xT/pk8NlPzIswscgFUiVYjJW OItrb5P6Xh4OZCJqLxWnv2dIxIOmlSXL87niOnHCx8P7gscLyWVdPcmxxJJp1bOg2TGG F80KHNVGRW2i2jW2YpNGRP11OtAQR0QLRoIrFWnH+ukd9znD8aIQCzLWNFXKGqfz4bRc h5+A== X-Gm-Message-State: AOAM5334ItBepWhxdC5ghRCZXo+ahwaSJAB6NxwOn/M9FLvY4orquOgM xPEABgXDc1m7bcpP99Wf7+acFe2N665RwNdUYzM= X-Google-Smtp-Source: ABdhPJw8QKchs1Q88WpqCNg0e2MXNHiagHE8gm77cXpJYTIs6V6UwwPQ1ZRJHjjq0qzIHWI3FFlYpEwk3s0t8XYAsCk= X-Received: by 2002:a9f:3f0d:: with SMTP id h13mr11764616uaj.100.1627286029015; Mon, 26 Jul 2021 00:53:49 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20210723191023.GG25548@kadam> <162717033769.3676.6942299974175827854@noble.neil.brown.name> In-Reply-To: From: Geert Uytterhoeven Date: Mon, 26 Jul 2021 09:53:37 +0200 Message-ID: Subject: Re: Potential static analysis ideas To: Arnd Bergmann Cc: NeilBrown , Laurent Pinchart , Dan Carpenter , ksummit@lists.linux.dev, Julia Lawall Content-Type: text/plain; charset="UTF-8" Hi Arnd, On Mon, Jul 26, 2021 at 9:26 AM Arnd Bergmann wrote: > On Sun, Jul 25, 2021 at 1:45 AM NeilBrown wrote: > > On Sun, 25 Jul 2021, Laurent Pinchart wrote: > > > > To make it work well, you need to know if frob() and/or the current > > > > function return an error code or not. While you can use some heuristics > > > > (e.g. is there any return -Exxx), perhaps we can add an annotation to > > > > indicate if a function returns an error code, or an error pointer? > > > > > > https://lore.kernel.org/linux-media/YNMvarFl%2FKU1pGCG@pendragon.ideasonboard.com/ > > > > > > I think it would be useful, if not for the tools, at least for > > > developers. > > > > Agreed. I added some code to smatch so that I could annotate pointers to > > say if they are allowed to be NULL. The implementation isn't perfect, > > but I love having that extra documentation about when I do or don't have > > to check for NULL. > > I can think of four different annotations that limit what a pointer return from > a function can be: > > a) either a valid pointer or NULL, but never an error pointer, > b) either a valid pointer or an error pointer, but not NULL, > c) always a valid pointer, never NULL or an error, > d) always NULL, but callers are expected to check for error pointers. e) either a valid pointer, NULL, or an error pointer The last pattern is seen with the various *get*_optional() functions. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds