[ChrisMarshallNY]

It’s not too difficult, if you do it from the start, and by habit.

I have an xcconfig file[0], that I add to all my projects, that turns on treat warnings as errors, and enables all warnings. In C, I used to compile -wall.

I also use SwiftLint[1].

But these days, I almost never trigger any warnings, because I’ve developed the habit of good coding.

Since Magic Lantern is firmware, I’m surprised that this was not already the case. Firmware needs to be as close to perfect as possible (I used to write firmware. It’s one of the reasons I’m so anal about Quality).

[0] https://github.com/RiftValleySoftware/RVS_Checkbox/blob/main... (I need to switch the header to MIT license, to match the rest of the project. It’s been a long time, since I used GPL, but I’ve been using this file, forever).

[1] https://littlegreenviper.com/swiftlint/

[names_r_hard]

It's not firmware :) We use what is probably engineering functionality, built into the OS, to load and execute a file from disk. We run as a (mostly) normal program on the cam's normal OS.

We build with: -Wall -Wextra -Werror-implicit-function-declaration -Wdouble-promotion -Winline -Wundef -Wno-unused-parameter -Wno-unused-function -Wno-format

Warnings are treated as errors for release builds.

[ChrisMarshallNY]

Awesome!

Great work, and good luck!

[names_r_hard]

Thanks, and for what it's worth, I didn't downvote you (account is too new to even do so :D ), and I agree with your main point - it's not that hard to avoid all compiler warnings if you do it from the start, and make sure it's highly visible.

You only add one at a time, so you only need to fix one at a time, and you understand what you're trying to do.

It is, however, a real bitch to fix all compiler warnings in decade old code that targets a set of undocumented hardware platforms with which you are unfamiliar. And you just updated the toolchain from gcc 5 to 12.

[ChrisMarshallNY]

Oh, don't worry about the downvotes. Happens every time someone starts talking about improving software Quality around here.

Unpopular topic. I talk about it anyway, as it's one of my casus belli. I can afford the dings.

BTW: I used to work for Canon's main [photography] competitor, and Magic Lantern was an example of the kind of thing I wanted them to enable, but they were not particularly open to the idea -control freaks.

Also, it's a bit "nit-picky," I know, but I feel that any software that runs on-device is "firmware," and should be held to the same standards as the OS. I know that Magic Lantern has always been good. We used to hear customers telling us how good it was, and asking us to do similar.

I think RED had something like that, as well. I wonder how that's going?

[names_r_hard]

Okay, good, just making sure :) Fun to hear that at least some photo gear places are aware of ML!

I have done a stint in QA, as well as highly aggressive security testing against a big C codebase, so I too care a lot about quality. And you can do it in C, you just have to put in the effort.

I'd like to get Valgrind or ASAN working with our code, but that's quite a big task on an RTOS. It would be more practical in Qemu, but still a lot of effort. The OS has multiple allocators, and we don't include stdlib.

Re firmware / software, doesn't all software run on a device? So I suppose it depends what you mean by a device. Is a Windows exe on a desktop PC firmware? Is an app from your phones store firmware? We support cams that are much more powerful than low end Android devices. Here the cam OS, which is on flash ROM, brings the hardware up, then loads our code from removable storage, which can even be a spinning rust drive. It feels like they're firmware, and we're software, to me. It's not a clearly defined term.

The main reason I make the distinction is because we get a lot of users who think ML is like a phone rom flash, because that's what firmware is to most people. Thus they assume it's a risky process, and that the Canon menus etc will be gone. But we don't work that way.

[ChrisMarshallNY]

Good point, and really just semantics. I guess you could say native mobile apps are “firmware,” using my criteria.

But I put as much effort into my mobile apps, as I did, into my firmware projects (it’s been decades since I wrote firmware, BTW. The landscape is quite different, these days -This is my first ever shipped engineering project[0]. Back then, we could still use an ICE to debug our software).

It just taught me to be very circumspect about Quality.

I do feel that any software (in any part of the stack) I write that affects moving parts, needs to be quite well-tested. I never had issues with firmware, but drivers are another matter. I've fried stuff that cost a lot.

[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf

[aorth]

Great, thanks for sharing the links.

By the way, rift valley software? I'm writing to you from Kenya, one of the homes of the great rift valley. It is truly remarkable to drive down the escarpment just North of Nairobi!

[ChrisMarshallNY]

I used to live in Uganda.

Visiting the Rift Valley in Southwest Uganda was one of the most awesome experiences of my childhood. My other company, Little Green Viper, riffs on that, too.

I was born in Africa, and spent the first eleven years of my life, there.

Had to leave Uganda in a hurry, though (1973).