Resume
ShivResume1.docx Description: MS-Word 2007 document
Re: [PATCH] PR 106003
Thank you. I've committed the patch, and it is covered by the Developer Certificate of Origin (DCO). Immad. On Sat, Jul 2, 2022 at 9:02 PM David Malcolm wrote: > On Sat, 2022-07-02 at 19:34 +0530, Mir Immad wrote: > > From 62b7b7736975172f03b30783436fbc9217324223 Mon Sep 17 00:00:00 2001 > > From: mir > > Date: Sat, 2 Jul 2022 15:04:37 +0530 > > Subject: [PATCH] analyzer: implement five new warnings for misuse of > > POSIX > > file descriptor APIs [PR106003]. > > > > This patch adds a new state machine to the analyzer for checking usage > > of > > POSIX file descriptor > > APIs with five new warnings. > > > > It adds: > > - check for FD leaks (CWE 775). > > - check for double "close" of a FD (CWE-1341). > > - check for read/write of a closed file descriptor. > > - check whether a file descriptor was used without being checked for > > validity. > > - check for read/write of a descriptor opened for just writing/reading. > > > > gcc/ChangeLog: > > PR analyzer/106003 > > * Makefile.in (ANALYZER_OBJS): Add sm-fd.o. > > * doc/invoke.texi: Add -Wanalyzer-fd-double-close, -Wanalyzer-fd-leak, > > -Wanalyzer-fd-access-mode-mismatch, -Wanalyzer-fd-use-without-check, > > -Wanalyzer-fd-use-after-close. > > > > gcc/analyzer/ChangeLog: > > PR analyzer/106003 > > * analyzer.opt (Wanalyzer-fd-leak): New option. > > (Wanalyzer-fd-access-mode-mismatch): New option. > > (Wanalyzer-fd-use-without-check): New option. > > (Wanalyzer-fd-double-close): New option. > > (Wanalyzer-fd-use-after-close): New option. > > * sm.h (make_fd_state_machine): New decl. > > * sm.cc (make_checkers): Call make_fd_state_machine. > > * sm-fd.cc: New file. > > > > gcc/testsuite/ChangeLog: > > PR analyzer/106003 > > * gcc.dg/analyzer/fd-1.c: New test. > > * gcc.dg/analyzer/fd-2.c: New test. > > * gcc.dg/analyzer/fd-3.c: New test. > > * gcc.dg/analyzer/fd-4.c: New test. > > [...snip...] > > Hi Immad. > > Thanks for the updated patch. > > For everyone else, we've been discussing this patch off-list. We've > had some issues with gmail mangling patches; FWIW a pristine version of > the patch can be seen at: > https://mirimmad.github.io/patch-02-07.txt > > As discussed off-list, you've successfully bootstrapped this patch and > run the testsuite without regressions (and a bunch of extra PASSes), so > this patch is ready for you to push it to the "master" git branch (aka > trunk). Please go ahead with that (or let me know if you need help > [1]). > > Note that Tim's first analyzer patch is also ready to push, so there's > a chance that your patches might conflict with each other (though I > think you're touching different areas of the analyzer, so I'm hoping > that won't happen). > > There's plenty of scope for followups, such as adding attributes for > parameters that expect an open file-descriptor, or for handling socket > APIs, etc. Also, Murphy's Law means that there's sure to be at least > something we missed in review :/ > > Let's move followup patches to the gcc-patches mailing list, rather > than the "gcc" list. > > Thanks > Dave > > [1] though I'll only be checking email intermittently this weekend and > on Monday (which is a holiday here in the USA). > >
Re: [PATCH] PR 106003
On Sun, 2022-07-03 at 14:36 +0530, Mir Immad wrote: > Thank you. > I've committed the patch, and it is covered by the Developer > Certificate > of Origin (DCO). Excellent - thanks. Congratulations on getting your first patch into GCC! Dave
Re: analyzer: implement five new warnings for misuse of POSIX
On Sun, 2022-07-03 at 02:46 +, 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
gcc-13-20220703 is now available
Snapshot gcc-13-20220703 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20220703/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision f3a5e75cb66dc96efca7d494fe6060746c88acb1 You'll find: gcc-13-20220703.tar.xz Complete GCC SHA256=1e53e47ca955eda8eb0b477befa0a087ce057b39e7f8b8943a280d5d3028ce14 SHA1=caff25e745f708d14d4394266daa7990748f9be6 Diffs from 13-20220626 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
