public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use a zero-size array in the struct devres
Date: Tue, 06 Mar 2007 23:58:23 +0900	[thread overview]
Message-ID: <45ED818F.2030502@gmail.com> (raw)
In-Reply-To: <tnx649emo55.fsf@arm.com>

Catalin Marinas wrote:
> Chapter 5.31 (http://gcc.gnu.org/onlinedocs/gcc/Alignment.html) states
> that "it is an error to ask for the alignment of an incomplete type"
> and flexible array members have incomplete type (according to ISO C99
> as described in http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html).
> 
> It sounds to me like the alignment of an incomplete type is not
> guaranteed (as you can't even enquire about it, though I might be
> wrong). This is probably dependent on the compiler as well - with
> gcc-3.3 on x86, __alignof__(unsigned long long) is 8 but the
> "offsetof(struct test, data)" below is 12 (and it doesn't make any
> difference whether it is a 0-size array or not):
> 
> struct test {
>     unsigned long a;
>     unsigned long b;
>     unsigned long c;
>     unsigned long long data[];
> };

data[0] and data[1] or whatever will also give you offset of 12.  Dunno
why, but it is.  Anyways, whatever the wording in the manual is,
flexible arrays just have to have the required alignment to do its job
as advertised.  :-)

>>> I came across this when trying to build kmemleak as the modified
>>> container_of macro tries to get the size of the devres.data member and
>>> sizeof cannot be applied to incomplete types.
>> If kmemleak's container_of cannot deal with the current struct devres,
>> it means it can't deal with flexible arrays at all.  Flexible array
>> being the standard as opposed to 0 size array gcc extension, I guess a
>> lot of people would prefer flexible array.
> 
> I'm OK with flexible arrays (kmemleak uses them as well) but not as a
> member of structure getting passed to the container_of macro.
> 
> I did a quick grep through the kernel and it looks like Linux mainly
> uses 0-size rather than flexible arrays at the end of a structure
> (>500 vs ~14). This might be for historical reasons but it's not a big
> issue in modifying them.

I think it's mostly historical.  Flexible array is still a relatively
new thing.  I don't mind changing devres to zero sized array, but please
explain in the commit message and as a comment that the choice is for
kmemleak's container_of(), and cc Greg K-H as the change should probably
go through his tree.

Thanks.

-- 
tejun

  reply	other threads:[~2007-03-06 14:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-06  9:54 [PATCH] Use a zero-size array in the struct devres Catalin Marinas
2007-03-06 12:44 ` Tejun Heo
2007-03-06 14:40   ` Catalin Marinas
2007-03-06 14:58     ` Tejun Heo [this message]
2007-03-06 15:21       ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45ED818F.2030502@gmail.com \
    --to=htejun@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox