On 09/17/14 04:30, Herbert Xu wrote:
On Wed, Sep 17, 2014 at 02:15:40PM +0300, Dmitry Kasatkin wrote:
On 17/09/14 12:22, Herbert Xu wrote:
On Mon, Sep 15, 2014 at 12:30:23AM -0700, behanw@xxxxxxxxxxxxxxxxxx wrote:
From: Behan Webster <behanw@xxxxxxxxxxxxxxxxxx>
Add a macro which replaces the use of a Variable Length Array In Struct (VLAIS)
with a C99 compliant equivalent. This macro instead allocates the appropriate
amount of memory using an char array.
The new code can be compiled with both gcc and clang.
struct shash_desc contains a flexible array member member ctx declared with
CRYPTO_MINALIGN_ATTR, so sizeof(struct shash_desc) aligns the beginning
of the array declared after struct shash_desc with long long.
No trailing padding is required because it is not a struct type that can
be used in an array.
The CRYPTO_MINALIGN_ATTR is required so that desc is aligned with long long
as would be the case for a struct containing a member with
CRYPTO_MINALIGN_ATTR.
Signed-off-by: Behan Webster <behanw@xxxxxxxxxxxxxxxxxx>
Acked-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Thanks,
Just in case.
I would still follow advice from "Michał Mirosław" to use shash##__desc[]
Absolutely. I will be posting a v4 patchset . Just waiting a bit more
for more comments on v3.
The macro from v4 will look like this which I believe will satisfy the
concern and indeed be safer than my previous version.
+#define SHASH_DESC_ON_STACK(shash, tfm) \
+ char __##shash##_desc[sizeof(struct shash_desc) + \
+ crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR; \
+ struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
Hmm. Is it worth adding a comment with this macro explaining the reason this works? Essentially much of what is in the commit message?
Oh yes of course. My ack is more about the approach.
Wonderful!
Indeed. I would have asked for you to wait for v4 anyways. :)
Thank you,
Behan
--
Behan Webster
behanw@xxxxxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
