This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] gdbserver/hostio.c, handle_close: check for null
- From: Michael Snyder <msnyder at vmware dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Mon, 14 Mar 2011 14:27:03 -0700
- Subject: Re: [RFA] gdbserver/hostio.c, handle_close: check for null
- References: <4D71488B.8000304@vmware.com> <201103141352.09214.pedro@codesourcery.com>
Pedro Alves wrote:
On Friday 04 March 2011 20:16:11, Michael Snyder wrote:
This one's a little iffey...
The conditional in the while loop implies that the pointer may wind up
as null. Therefore it would make sense to check it for null before
dereferencing it.
Alternatively, if it can't wind up as null, we should take the test out
of the while loop.
It can't wind up as null here. The require_valid_fd() call up
in the function makes sure 'fd' exists in the list.
Either a gdb_assert or removing the check is fine. But
in either case, it'd be nice if it came with a comment
mentioning why it can't be NULL.
OK, committed as attached.
Thanks.
2011-03-14 Michael Snyder <msnyder@vmware.com>
* gdbserver/hostio.c (handle_close): Remove unnecessary null test.
Index: hostio.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/hostio.c,v
retrieving revision 1.14
diff -u -p -r1.14 hostio.c
--- hostio.c 28 Feb 2011 15:55:08 -0000 1.14
+++ hostio.c 14 Mar 2011 21:20:30 -0000
@@ -418,7 +418,8 @@ handle_close (char *own_buf)
}
open_fd_p = &open_fds;
- while (*open_fd_p && (*open_fd_p)->fd != fd)
+ /* We know that fd is in the list, thanks to require_valid_fd. */
+ while ((*open_fd_p)->fd != fd)
open_fd_p = &(*open_fd_p)->next;
old_fd = *open_fd_p;