lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 8 Apr 2012 17:59:59 -0600
From:	Jim Cromie <jim.cromie@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [00/02] add BUILD_BUG_DECL assertion (for 3.4??)

On Sun, Apr 8, 2012 at 4:52 PM, Joe Perches <joe@...ches.com> wrote:
> On Sun, 2012-04-08 at 16:38 -0600, Jim Cromie wrote:
>
>> this patch (0001) adds new bug.h macro, BUILD_BUG_DECL(name, cond),
>> which unlike other *BUG* assertions is usable at file scope.  Its
>> primary purpose is to enforce identical sizes of 2 separate arrays,
>> which but for considerations of packing/padding/section, would be
>> together in a struct.
>>
>> const char const *names[] = { "bart", "lisa", "homer", "marge" };
>> int a[] = {1,2,3,4};
>> int b[] = {1,2,3,5};
>> long d[] = {1,2};
>>
>> BUILD_BUG_DECL(foo, ARRAY_SIZE(a) != ARRAY_SIZE(b));
>> BUILD_BUG_DECL(buz, sizeof(a) != sizeof(b));  // good
>> BUILD_BUG_DECL(a, sizeof(a) != sizeof(d));    // ok on x32, error x64
>> BUILD_BUG_DECL(b, ARRAY_SIZE(a) != ARRAY_SIZE(names));        // good
>>
>> macro expands as:
>> static __attribute__ ((__section__(".init.data"))) struct {
>>        int BUILD_BUG_DECL_buz[1 - 2*!!(sizeof(a) != sizeof(b))];
>> } BUILD_BUG_DECL_buz[0] __attribute__((unused));
>>
>
> If possible, it might be better to wrap the
> declarations themselves in a macro that ensures
> the sizes are the same.
>
> Something like:
>
> declare_same_size_arrays(
>        typeof array1[] = {...},
>        typeof array2[] = {...}
> );
>
>

Unless Im mis-reading you, this has a couple disadvantages:

- bigger patches where its added.
granted these are mostly whitespace, but theyre less trivial to inspect.

- not useful for array definitions which are not contiguous
granted thats a minority case, and the definitions could often be moved,
but not always.

WAG: If *80211 code were to export tables that drivers could use,
(say standardized frequency, channel stuff)
it would be helpful if the drivers could assert that their private tables match
the exported ones.  (I havent looked in *80211, or tried using
BUILD_BUG_DECL this way)

Do you see advantages other than stylistic ones ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ