Re: RFC - C99 issue regarding unnamed union/structs


Flavio Ceolin
 

Hi,

In order:

1. Empty structs are really useful, for example the spot you're noticing
that allows arch code to define its own set of private data, which might
be zero-length.  Obviously that could be worked around with appropriate
preprocessor trickery (e.g. CONFIG_ARCH_HAS_CALLER_SAVED_STRUCT or
something similarly wordy), but not as cleanly.
I'm with Thomas, this is a GCC extension we should rely on them.


2. That looks wrong.   We should surely be using a consistent way to
specify packed structs.
Thumbs up


3. Flexible arrays are valid C99.  You mean a literal zero in the
brackets in the declaration?  Yeah, that's the wrong syntax, the
standard specifies "[]" for this.
Literal zero is GCC extension and about flexible array "[]" it can be
used *only* as the last element in a struct (and this struct cannot be
used in array or inside other struct/union - GCC allows it).



4. That's a "case '1' ... '9':" expression to detect decimal digits in
the middle of an otherwise giant switch.   Sure, I guess we could turn
that into nine separate case labels, but wow is it nicer this way and
boy is it a useful feature that the compiler gives us to express this. 
Hint, hint.

5. Dynamic stack allocation (via either variable arrays or alloca()) is
problematic for a various reasons (some dumb, but some good -- note that
systemd just got hit by a local root exploit last week due to an
attacker-controlled alloca!), and I'm actually the worst offender in the
current tree.   These are likely all going to have to go away soon, or
at least be reworked into a form such that the code will build without
dynamic stacks.
Yeah, remove alloca usage is something that is being tracked (in some
issues actually). e.g >https://github.com/zephyrproject-rtos/zephyr/issues/9892

Andy


On 1/15/2019 12:47 AM, Thomas Törnblom wrote:
While on the subject of language compliance, what about the frequent
usage of non-standard gcc extensions that limits portability?

I've started looking at making IAR Embedded Workbench a supported tool
chain for Zephyr, and while I have not looked at the cmake build tools
yet, I've tried to build one of the examples (hello) using our IDE,
and have run into several non-standard things like:

1) Empty structs (struct _caller_saved in kernel_arch_thread.h)

2) Packed structs, "struct __packed__ ..." vs "__packed struct .." or
"struct __attribute__((__packed__)) ...", the latter two variants are
accepted by our tools, the first is not ( _k_thread_stack_element in
kernel.h)

3) Zero sized arrays (several places in the include files for logging)

4) Ellipses/ranges in case (printk.c)

5) alloca

Of these alloca() is probably the most problematic for us as we have
no alloca, and no easy way to implement it either as we have no frame
pointer. In one place I could use a variable size array, but the rb
code requires more work, and I would really prefer not having to use
the variable size array either.

Comments?

/Thomas

Den 2019-01-14 kl. 22:11, skrev Peter A. Bigot:
I don't have a solution, but since the question came up I am
interested in any reaction to
https://github.com/zephyrproject-rtos/zephyr/issues/9552#issuecomment-449718078
since that's relevant to the topic.

Peter

On 1/14/19 1:47 PM, Flavio Ceolin wrote:
Hi guys,

One problem with have in Zephyr regarding C99 is that we are using a
lot
of unnamed struct/unions. One example is:

--

*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom@iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Regards,
Flavio Ceolin

Join devel@lists.zephyrproject.org to automatically receive all group messages.