Compiler Warnings when Compiling under Visual Studio

Feature request
1

Hello,

I’m recently compiling LVGL V9 very frequently under Windows using Vistual Studio.
The MS compiler seems to have different ideas of when to issue a warning (o;
It is especially picky about “possible datalosses” due to different size of variables during an assignment.
I think most thes warnings are just that, but to get rid of them a typecast must be added, for example:

lv_spinbox.c, Line 319
spinbox->step = lv_pow(10, spinbox->digit_count - 2);

spinbox->step is a int32_t while lv_pow returns and int64_t.

I would be more than happy to supply pull requests to fix these warnings, but before I go down that road I would like to know if you are willing to merge them.

I’m fine if you say you don’t care about these warnings, I just want to know before I start the work.

Thanks,
Martin

2

Hi Martin,

The most beautiful words words to my ears (eyes) :slight_smile:

I would be happy merge the fix for these warnings. Thank you in advance!

3

OK, than I will add the casts.
If this is ok for you I will split the changes into multiple pull requests.
That way I can do a few at a time and I think it will also be easy for you to check if I miss understood the code and added the wrong cast.

Martin

1 Like
4

Another quesion just come into my mind.

I would like to add these casts to the V9 release branch and the master branch.

  • So I would make the changes to the V9 branch → create the pull request
  • Merge the changes to the master branch → create the pull request

Would that be OK?

Martin

5

We will release v9.1 next week Tuesday (Marc 19). If you can add the changes by that, I think it’s ok to update only LVGL master as we will have a release/v9.1 branch from that too.

6

Oh, thanks great. That will save me some time.
I started yesterday looking at it.
There are a lot of warnings comming from “3rd party libraries” like LodePNG, code128, TJpgDec , …
Especially the 64bit build is really heavy on warnings because in a 64bit environment the size_t type is 64bit and throughout lvgl (and the 3rd party libs) it is assumed that the size_t is 32bits.

What’s your thought on how the handle the 3rd party code parts.
If try to fix most of the warnings there, once and update of these files from the external source is made all these changes will be gone again…

Martin

7

The 3rd party libs is really a complicated question. Could you fix only e.g. code128 first to see how many changes are required?

8

OK, I will start with the fixes for the “core” library in a first run.
Than I will look at the 3rd party files

1 Like
9

@kisvegabor
I have a small issue/question regarding teh handling of size_t warnings when compiling on 64bit systems.
size_t on 64bit machines is 64bits wide.

lvgl assumes that size_t is 32bits and use a mix of uint32_t and size_t as types, for example:
lv_lru.c, Line 194:

uint32_t hash_index = lv_lru_hash(cache, key, key_size);

Here key_size is size_t but the lv_lru_hash functions requires a uint32_t parameter.We have two options now

  1. Make the cast when calling the lv_lru_hash function
  2. change the lv_lru_hash function to use size_t instead of uint32_t

There are many places in the current source code where this happens. So before I do something here I would to to clairfy that with you.

Personally, I would choose option 2 (change the sigature of lv_lru_hash function to use size_t instead of uint32_t.
What’s your thoughts on that?

Thanks
Martin

10

I agree to change the signature. If we rely on casting, sooner or later people will forget it.

11

Is it possible to run all the checks made for a oull request before I createte pull request.
Especially the changes for the uint32_t->size_t for the file system access is hug and I cannot test for all platforms…

Thanks
Martin

12

You can run most of the tests by following the instructions here. Note that the tests are designed to run on Linux.

13

I can put together a test to compile under Windows if you like… Can do that using CMAKE or I can use some python code to set up the build environment and to compile LVGL. Either way it will use MSVC. Too many times I have compiled LVGL with the demos and examples only to have it fail under Windows. It will succeed on Linux though.

14

I use cmake file provioded by lvgl to generate the VSVC project. The works really well

15

The reason why I mentioned the python way is because of speed. I am able to compile LVGL in ~6 seconds if I don’t use cmake. Speed is one of those things that is important when compiling using a CI.