From: rpjday@crashcourse.ca (Robert P. J. Day)
To: kernelnewbies@lists.kernelnewbies.org
Subject: variant length array?
Date: Tue, 5 Apr 2016 14:16:31 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.20.1604051416090.11936@localhost.localdomain> (raw)
In-Reply-To: <8760vvygeo.fsf@nemi.mork.no>
On Tue, 5 Apr 2016, Bj?rn Mork wrote:
> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> > On Tue, 5 Apr 2016, Wenda Ni wrote:
> >
> >> Hi all,
> >>
> >> I come across the following code in a kernel module code. It defines
> >> an array whose length is variant at runtime, depending on the actual
> >> inputs. It seems that kernel compiler supports this, which is
> >> obvious an error in the standard ANSI C. Do I have the correct
> >> understanding on it?
> >>
> >> Thank you.
> >>
> >>
> >> u32 rxe_icrc_hdr(struct rxe_pkt_info *pkt, struct sk_buff *skb)
> >> {
> >> ???????? ...
> >> ???????? int hdr_size = sizeof(struct udphdr) +
> >> ???????????????? (skb->protocol == htons(ETH_P_IP) ?
> >> ???????????????? sizeof(struct iphdr) : sizeof(struct ipv6hdr));
> >> ???????? u8 tmp[hdr_size + RXE_BTH_BYTES];
> >> ???????? ...
> >> }
> >
> > pretty sure "sizeof" can be calculated at compile time so i don't
> > see a problem here.
>
> Yes, but skb->protocol is variable and sizeof(struct iphdr) !=
> sizeof(struct ipv6hdr)). Is the compiler smart enough to just use the
> largest possible value? The logic here is pretty similar to a union,
> which it of course wouldn't have any problems calculating the size of.
ah, quite so, i didn't look closely enough.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
next prev parent reply other threads:[~2016-04-05 21:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 19:29 variant length array? Wenda Ni
2016-04-05 19:43 ` Robert P. J. Day
2016-04-05 20:00 ` Bjørn Mork
2016-04-05 20:23 ` Rajat Sharma
2016-04-05 21:16 ` Robert P. J. Day [this message]
2016-04-05 20:19 ` Valdis.Kletnieks at vt.edu
2016-04-05 20:29 ` Wenda Ni
2016-04-06 10:51 ` Bernd Petrovitsch
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=alpine.LFD.2.20.1604051416090.11936@localhost.localdomain \
--to=rpjday@crashcourse.ca \
--cc=kernelnewbies@lists.kernelnewbies.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;
as well as URLs for NNTP newsgroup(s).