Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1427501
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] rxrpc: fix uninitialized variable use |
| Date | 2016-06-21 11:30 +0200 |
| Message-ID | <rMqal-3Th-13@gated-at.bofh.it> (permalink) |
| References | <rKYJc-4U2-17@gated-at.bofh.it> <rMpHj-3tJ-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tuesday, June 21, 2016 9:48:52 AM CEST David Howells wrote: > Arnd Bergmann <arnd@arndb.de> wrote: > > > Hashing the peer key was introduced for AF_INET, but gcc > > warns about the rxrpc_peer_hash_key function returning uninitialized > > data for any other value of srx->transport.family: > > > > net/rxrpc/peer_object.c: In function 'rxrpc_peer_hash_key': > > net/rxrpc/peer_object.c:57:15: error: 'p' may be used uninitialized in this function [-Werror=maybe-uninitialized] > > > > Assuming that nothing else can be set here, this changes the > > function to just return zero in case of an unknown address > > family. > > I'm actually more tempted to put a BUG() in there because if any new family > support (say AF_INET6) is added, I want to make sure I catch all the places. Makes sense. Do you want to do the patch yourself, or should I send a new one doing that? Maybe WARN() would be better than BUG()? That would still get the attention it needs but not kill the process. Arnd
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] rxrpc: fix uninitialized variable use Arnd Bergmann <arnd@arndb.de> - 2016-06-17 12:00 +0200
Re: [PATCH] rxrpc: fix uninitialized variable use David Howells <dhowells@redhat.com> - 2016-06-21 11:00 +0200
Re: [PATCH] rxrpc: fix uninitialized variable use Arnd Bergmann <arnd@arndb.de> - 2016-06-21 11:30 +0200
Re: [PATCH] rxrpc: fix uninitialized variable use David Howells <dhowells@redhat.com> - 2016-06-21 12:10 +0200
csiph-web