Closed palhaland closed 1 year ago
I don't see an issue here.
No issues, I just wanted to contribute and needed a decision on what action to do. If there are no issues here, then I assume the associated code can be removed? If you don't mind I'll make a pull request on it.
Alternatively everything that is related to debug can use a compile-flag if it is going to be included.
(Started running clang --analyze on the code)
what I mean is the code will stay. As it is.
On Mon, 27 Mar 2023, 08:14 Pål Håland, @.***> wrote:
No issues, I just wanted to contribute and needed a decision on what action to do. If there are no issues here, then I assume the associated code can be removed? If you don't mind I'll make a pull request on it.
Alternatively everything that is related to debug can use a compile-flag if it is going to be included.
(Started running clang --analyze on the code)
— Reply to this email directly, view it on GitHub https://github.com/wiedehopf/readsb/issues/29#issuecomment-1484555756, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVHFLCZTEVIGS45PBLPEKTW6EV3HANCNFSM6AAAAAAWIGXLPQ . You are receiving this because you commented.Message ID: @.***>
Please don't get me wrong if there is a bug or you want to add some feature, i'm open to pull requests.
I'd even consider other (manually found) cleanups or adding comments where i consider it a positive change.
But stuff static code analyzers are just not something i'm interested in. I mean if the static analyzer finds a bug or some memory unsafe thing i'll consider it. But this change wouldn't change the compiled code. I left this stuff in for future work or debugging of the respective functions. I'd then remove && 0 to reactivate an old behaviour or turn on the debug output. Having it all behind a general debug flag would make the log unreadable pretty much. I suppose one could add sensible debug flags for several logic parts, but i'm not sure it's worth it.
And in regards to code readability: Anyone serious about working on the code will see this stuff as deactivated. Doing a block comment or ifdef might be cleaner but i like this style as it's super quick for me to do.
The reality is, since i forked readsb i've done 99.9% of code changes. So mostly i'll accept performance improvements / bug fixes / features added. Features need to be opt in via command line if they use significant resources.
There are a couple of ifs that always will evaluate to 0, should these be removed, replaced with a macro, or removed the
0 &&
so that they are compiled in?A lot of them are debug (fprintf).