In #664 I added a test that determines if the supplied compiler
understands the `-fno-delete-null-pointer-checks` flag. The problem is
that the `$(CC)` supplied on command line or in the application's
Makefile is used, but not the one the `$(BOARD)`'s Makefile sets.
That problem was overlooked as all the boards use GCC, and GCC happens
to know the flag. But if some future board does not use GCC, then the
wrong order of the checks could pose a problem.
An application might want to use C11 features. The user would assume
that setting `CFLAGS=-std=gnu11` in the Makefile would work. It does not
since the board's Makefile.include shadows the `-std` flag.
This patch removes the `-std=gnu99` from the various Makefile.includes,
and sets the flag in the common Makefile.include of RIOT instead.
If an `-std` flag was provided by an earlier Makefile (the application,
the board, or the CPU [whilst only the former one should]), then no
additional flag is set. It is first tested if the supplied compiler
understands `-std=gnu99`, then `-std=c99`.
test_thread_msg_block_w_queue:
demonstrates the behaviour described in issue #100
and that it is solved by PR #569
test_thread_msg_block_wo_queue:
demonstrates behaviour similar to the above but without
a messge queue. This works with the current master, but
breaks with PR #569
When setting the running task reply_blocked, it is implicitly removed
from the runqueue. But if queueing of a msg is actually successful, the
thread exits msg_send without yielding, continuing to run even if it's
not supposed to.
Nice example of why multiple function exit points lead to weird
errors...
All other layers in the network stack use a msg_queue to not drop messages, which in this context represent packages.
This finally fixes the random crashes when UDP network traffic is present. Turns out RIOT is not handling lost messages well.
msg_queue is defined but never used, hook it up so IP packets get queued instead of dropped when there is more than one.
change the name to ip_msg_queue to avoid naming conflicts.
