Den 2019-01-15 kl. 17:45, skrev Andy
Ross:
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.
Would there be a problem adding a single anonymous member to this to
make it standards compliant?
After all, in C++ empty structs take up space while they don't with
gcc.
2. That looks wrong. We should surely be using a consistent way
to specify packed structs.
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.
Correct, just the extern declarations, which should be changed to
"[]".
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.
I agree that it sure looks convenient, but that switch is ~110 lines
of code, unrolling that case makes it 119 lines, and standard C.
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.
I'm glad to see that the issue with alloca is at least being
discussed
(
https://github.com/zephyrproject-rtos/zephyr/issues/9892).
I see it is a problem also with other vendors tools
(
https://github.com/zephyrproject-rtos/zephyr/issues/10182).
Andy
Would it be OK to fix issues 1 - 4 in a PR?
/Thomas
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:
