Re: Designated initializers, struct randomization and addressing?

2017-01-03 Thread Bruce Korb
As a tangential party, I am a bit curious: does the randomization plugin result in a compact structure? I ask because I know many/most programmers don't bother with it and so doing so ought to make the data more compact. On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook wrote: >> how is the code to be v

Re: [PATCH] staging: lustre: ldlm: use designated initializers

2016-12-20 Thread Bruce Korb
> > "{ NULL }" is valid ISO C, but unfortunately "{}" is not. Just make the thing "static const" and don't use an initializer. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: lustre: ldlm: use designated initializers

2016-12-19 Thread Bruce Korb
On Mon, Dec 19, 2016 at 8:22 AM, James Simmons >> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_flock.c >> @@ -143,7 +143,7 @@ static int ldlm_process_flock_lock(struct ldlm_lock >> *req, __u64 *flags, >> int added = (mode == LCK_NL);

Re: [PATCH 05/15] staging: lustre: ldlm: use accessor macros for l_flags

2016-04-27 Thread Bruce Korb
On 04/27/16 15:20, James Simmons wrote: From: Bruce Korb Convert most of the ldlm lock's l_flags references from direct bit twiddling to using bit specific macros. A few multi-bit operations are left as an exercise for the reader. The changes are mostly in ldlm, but also in llite, osc