Lint?

[pigrew]

Should we use lint? Should it be added to Travis-CI?

Here is the settings file I used with cppcheck which found issue #143.
tusb_stm32f070_dev.cppcheck.txt

The results are mostly instances of TU_ASSERT(false,), as cppcheck's parser fails on empty parameters in asserts (at least in C99 mode). There may be other issues, but I didn't notice anything else that was certainly a bug.

I also started looking at other linters. clang-tidy and clang-analyzer seem to be the most popular open-source tools.

TI's compiler (ARM or maybe MSP430; I forget which I used it with) does have a MISRA checker, but that means we'd need to use a closed source compiler, probably someone running it offline somewhere. The Tiva TM4C123G launchpad might be the easiest dev board to use since it's ARM, but it's a very unpopular MCU (maybe due to price?). I guess we could try to compile the code from within the TI CCS IDE. C2000 would be an interesting experiment due to its lack of 8-bit data types (IIRC, uint8_t does not exist), but the MSP430F5529 would be a more friendly experience with non-ARM MCUs.

Another possibly for linters is the Coverity scan project. It looks like they give free lint service to OSS projects.

[hathach]

yeah sure, though I don't know how to set up lint check to run on travis. If possible, would you please submit an PR for that, it will be very useful. If you don't have time, just give me a pointer. I will do it whenever I could :)

[pigrew]

@hathach , I think I requested access to tinyusb on Coverity Scan, but it may need your approval there?

Otherwise, I might just do things the manual way and try building code (with a null driver) for tiva, and see what its static analyzer says.

[hathach]

yeah sure thing, give me a link, I will approve it, more cool stuffs to work with 😄

[pigrew]

https://scan.coverity.com/

Someone already created a tinyusb project there? I think?

If you can't get to it, then maybe just "register a new github project".

[hathach]

@pigrew haha, I already had an account in the coverity site,I think I created that tinyusb project many years ago. The coverity name does ring a bell to me 😄

[hathach]

approved !!! Let's me know if I could do anything else to help :)

[pigrew]

Seems like "contributor" access can only view reports, not request analysis... oops.

Could you either set me at admin over there, or request a build? I don't know what configuration is required, but I assume it's non-trivial.

[hathach]

@pigrew yeah done

[pigrew]

@hathach I've spent the daily allotment of four builds. I've not gone through all the "issues", but they mostly exist in the MCU library code, not tinyusb itself. However, I'm not convinced I know how to use the tool properly, or that it knows that interrupts and MCU registers exist.

[hathach]

Mcu vendor is terrible of writing driver 😄😄, I often got to disable some warning, error inside board.mk to get bulding. One of the issue that prevent me to go all warnings, pendatic compilation. Later on I will try to learn and configure the tool as well. This is already very good, I recevied the scan report from coverity and they nake good points

[pigrew]

I marked a the few of them that looked important to take care of, so we can go back and make sure they are fixed. There was an I2C driver issue that might or might not be real.
I started to try playing with marking the endpoint handlers as handing out "tainted" data (from the attacker), but then their system stopped working (got build errors, can't see anything now).

There must be some trick on how to tell it to handle interrupts and volatile stuff... It seems much more for normal desktop programs.

The MISRA output from TI's compilers looked pretty good; though you have to disable the more silly things, like a ban on C++ style comments (the ones that use // ). It was reporting 1300+ warnings & errors.

[hathach]

Thanks for putting effort into this, that MISRA 98 is too old , the MISRA 2012 and above allow C99 features I remembered. The codebase doesn't use i2c except for ea4357 which use i2c gpio expansion. But it is our bug to worry about.

I will write more unit tests with unity and cmock later on to make sure all the control flow is covered and tested :)

PS: does coverity has a badge or something that we can put in our repo, it will be cool to show it to others *)

[pigrew]

Yep, they do have a badge. But, I'm too embarrassed to use it until I figure out if we're using the tool properly. I created a "coverity" branch in my fork for the latest build I submitted. I created an example which should include ALL of the class implementations (but still only BSP at a time).

I don't know if Coverity likes the same file being compiled multiple times, or not (like the build all script does). Errors keep popping in and out of existence in its reports. The latest one suggests that we add a few more TU_ASSERTS to confirm that descriptors actually exist before using them. Might not be a bad idea, but I don't want to bog down the code with too many checks (it's supposed to be tiny, after all.)

[hathach]

@pigrew hihi, it has been a long time, but I mange to get the coverity build tool and able to emit the file ready for analysis. I am trying to get it automation with github ci. Though I am not sure how should we submit it. Do you still remember how did you submit the cov-int last time.

1. Should we submit an tar cov-int for each build configuration e.g cdc_msc on stm32f072nucleo. That will be result in like 100 tar submission
2. Is there anyway we packed 100 build configures into a single tar that coverity could understand.

Like always, If you have no time to look at this, no worries, I will try to figure it out myself :)

 cov-build --dir cov-int make -j 4 BOARD=pca10056
Coverity Build Capture (64-bit) version 2019.03 on Linux 4.15.0-88-generic x86_64
Internal version numbers: 2c0f9c8cf4 p-pacific1-push-35439.872
......

CREATE _build/build-pca10056/pca10056-firmware.hex
   text	   data	    bss	    dec	    hex	filename
   2992	   1092	    104	   4188	   105c	_build/build-pca10056/pca10056-firmware.elf

Emitted 19 C/C++ compilation units (100%) successfully

19 C/C++ compilation units (100%) are ready for analysis
The cov-build utility completed successfully.