IAR compilation and some other errors/warnings

[king2]

OK, lets start.. this is warnings and errors I got while trying to compile library:

1. gtimer.c

Error[Pe118]: a void function may not return a value D:\Hardware\_projects\ugfx\src\gtimer\gtimer.c 111

Declaration of function is static DECLARE_THREAD_FUNCTION(GTimerThreadHandler, arg), DECLARE_THREAD_FUNCTION = threadreturn_t via define, threadreturn_t = void via typedef.

So, return 0 at end of void function is a error.

2. Many places where construction const XXX const is used, what generates Warning[Pe083]: type qualifier specified more than once.

3. init_board, read_byte, read_word (gmouse*) - empty functions that returns nothing, so Warning[Pe940]: missing return statement at end of non-void function generated. It will be better to include return statement even to sample non-void functions.

4. "point, point_t" and "GWindowObject, * GHandle" declaration - Warning[Pe301]: typedef name has already been declared (with same type)

5. gdisp.c: calling mf_render_aligned - Warning[Pe188]: enumerated type mixed with another type (justify).

6. gfx.h includes gdisp_rules.h and then gdisp.h (that includes gdisp_lld_config.h). So, defining GDISP_HARDWARE_PIXELREAD in gdisp_lld_config.h will still allow gdisp_rules.h do not know about GDISP_HARDWARE_PIXELREAD and generates warnings like GDISP_HARDWARE_PIXELREAD was not defined.

Should it be repaired?

[inmarket]

1. Which operating system are you using? Most operating systems define the thread return type as an int so gtimer is correct for them. Check the definition of that type in the gos source file for your operating system. If necessary for the moment either change the type definition or remove the return statement. Let us know and we will fix the issue for your operating system.

2. This form of const definition is an old style definition that means the pointer and the object it is referring to both need to be placed in code space. Unfortunately many modern compilers complain about it (although they still compile it correctly). Semantically however modern compilers are ambiguous. It is a nuionce that has been lost as cpu platforms have grown larger and this sort of functionality has become less important. In practice the code is technically correct and the (incorrect) compiler warning can be ignored.

3. I presume you are talking about a template board file that has been copied but not filled in with real code. In this case the warnings are appropriate as the template files are supposed to be copied into your project, renamed and filled in first. I suspect you have added the template file to your ide build list. If so just remove the template board files from your build list.

4. Can you please provide source file lines for the double definition as this seems strange and is something we will fix. It is unusual in that that is not a problem normally seen. Perhaps there is something wrong in your include lists?

5. This is a harmless warning and comes from the font code being derived from a third party (donated) library. The warning can be safely ignored.

6. I will check this one out. The gdisp driver inclusion order is very vomplex and changes depending on if you are using multiple display controller drivers. I will look and see if things are correct with respect to gdisp_rules.h. Is it causing you any particular problems?

[king2]

1. gos_freertos.h, line 54.

3. I got it, but even template file should be correct, isn't it?

4. "GWindowObject, * GHandle" - gwin.h line 55, "point, point_t" - gdisp.h line 53.

6. I do not know, as I understand its just generates false warnings to user while compiling.

To be precise, it is not complains, this is just feedback that I wrote thinking it can be helpful for you and for lib (but, sure, you can ignore it if you want).

[Joel Bodenmann]

king2 said:

To be precise, it is not complains, this is just feedback that I wrote thinking it can be helpful for you and for lib (but, sure, you can ignore it if you want).

No worries, we didn't take this as complains and we are very happy for any kind of feedback. Especially as this one is so well structured

Please keep it coming. It is in our own interest to fix every possible issue with the project. We will put everything onto the ToDo list - we are currently just working very slowly.

Update: We added the IAR and EDG compiler to the list of suported compilers and added the #pragmas required to handle the warnings: