Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 1 month ago.
mbed os 5 errors (induced by a bug/change in mbed platform or build process?)
Hi, I'm working with the nRF52 series target and mbed 5. I suspect there was a recent change in the build process or the mbed libraries that is causing some problems. Here's the scenario:
Many of my existing projects compile without error. (Ones that use mbed os 5).
When I create a new project (either cloning an existing project, creating a new project from a template for mbed os 5, or importing a published project), I see compiler errors. Specifically things about "equeue.c" (Ex: Expected an expression "for (unsigned s = size; s; s>>=1) {". There are 10 errors reported and most regard a for-loop where the condition is a simple variable name that's checking for non-null pointers). Since the errors are all in the mbed-os library and happen with both new templates and imports of working projects, I suspect there may have been a recent upgrade/change to mbed that is causing the problems.
I tried creating a project from one of the mbed 2 templates, and that worked fine. It seems to be confined to mbed os 5.
Any thoughts or suggestions? (Or is there anything I'm missing?)
1 Answer
8 years, 1 month ago.
TL;DR: Thanks for reporting this. It's a bug with the online compiler. The compiler should be working again. Let me know if it is still failing for you.
Long version: The root cause of the errors is an omission of the `-c99` flag, which turns on ISO C 99 mode, when compiling in the online compiler. The errors you are seeing are related to the fact that the compiler defaults to `-c89` instead, which turns on ANSI C 89 mode and does not allow you to declare new variables initialization section of a for loop. This bug only affected compiling C files today, and if you had been doing incremental compiles where the mbed-os library was compiled prior to this bug, the compiler would continue to use those saved object files without issue. We traced the omission back to it's source and found a fix for it.