Re: PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-19 Thread D. Hugh Redelmeier
Fixes have been proposed for this problem at least twice before. (These messages are not presented as a thread so I've put links to each of them) Problem report: Patch proposal: Reply suggesting improved

RE: PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-11 Thread D. Hugh Redelmeier
| From: David Laight | From: D. Hugh Redelmeier | > #define NLMSG_OK(nlh,len) ((len) >= (int)sizeof(struct nlmsghdr) && \ | >(nlh)->nlmsg_len >= sizeof(struct nlmsghdr) && \ | >(nlh)->nlmsg_len <= (len))

Re: PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-10 Thread D. Hugh Redelmeier
| From: David Miller | From: "D. Hugh Redelmeier" | Date: Wed, 9 Sep 2015 16:24:07 -0400 (EDT) | > 1) netlink(3) says that the type of the second parameter is "int". | >From the synopsis: | >int NLMSG_OK(struct nlmsghdr *nlh, int len); | >Surely

Re: PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-10 Thread D. Hugh Redelmeier
| From: David Miller | Everyone either uses an unsigned type (such as "size_t") or adds an | explicit cast to an unsinged type for the second argument. That sounded odd to me. So I looked through the Fedora code base, as indexed by searchcode.com. This took a stupid amount of time so I didn't

Re: PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-09 Thread D. Hugh Redelmeier
| From: David Miller | From: "D. Hugh Redelmeier" | Date: Tue, 8 Sep 2015 09:46:56 -0400 (EDT) | | > Using netlink.h's NLMSG_OK correctly will cause GCC to issue a warning | > on systems with 32-bit userland. The definition can easily be changed | > to avoid this. | |

PATCH: netdev: add a cast NLMSG_OK to avoid a GCC warning in users' code

2015-09-08 Thread D. Hugh Redelmeier
size_t. So I think that this would be safer: (nlh)->nlmsg_len <= (size_t)(len)) I know of no system where size_t is narrower than unsigned. This problem came up when building a userland component of libreswan in a 32-bit environment with a recent GCC and was reported by Lennart Sor