C DO code maintainablity issues

• [x] Look at TODOs in code.
• [ ] Clean C code, run callcatcher to delete dead code.
• [x] Change FFI so it's no longer casting to Double
• [x] Rename all occurrences of seq, especially in seq.* to something like dynamicCharacter, but not that, because it's already in use.

Removing a list item as it is a separate issue #60.

I think call catcher and similar static analysis for C sources are quite hard to get running. I think we will have to remove dead code manually, if at all.

@ima-hima should we prioritize this for the next week?

I'm working on an outside paper, and I also still need to spend some time documenting the Nexus parser and checking some of the TODOs and issues.

After the 18th I should have a lot of free time, though, at which point I want to do some work on seq-align, because paper. Since I'll be mucking about in C code at that point anyway, how 'bout I start then?

I would like to do this; I think it's something that could be pretty useful to me in future.

There's also, from what I can tell, a pretty decent static analyzer built in to either gcc or clang. I think I'll start there. If it brings up a lot of issues with code I think is dead then I'll do call catcher first.

Sound good?

Yeah, that does sound good.

I know gcc-7.* has a lot more static analysis flags. Unsure if there's one for listing functions which are never called. No Idea about clang's capabilities.

We can consider the the following flag invocations:

gcc -fdata-sections -ffunction-sections -Wl,--gc-sections

If gcc doesn't have the static analysis capabilities we need, Then I'm going to close out this issue.

I researched several C static analysis tools, but they all (mostly) want to mark what code was not executed for a specific run of the code, not perform static analysis of what code can never be executed on any run of the code. The idea was that you would have a large test suite to exercise the entirety of the codebase, and code that was not entered during this exercise is dead code. This isn't our use case, as we don't have a test suite for the C code.

I did try to clean out dead code by hand, but you know how that is.

I feel like I was a little lazy about unit testing here, but the truth is that the inputs and outputs were often opaque, and especially there was that assembly code, so I probably did about as good a job as could be expected.

e

On Jul 9, 2019, at 14:32, recursion-ninja [email protected] wrote:

We can consider the the following flag invocations:

gcc -fdata-sections -ffunction-sections -Wl,--gc-sections If gcc doesn't have the static analysis capabilities we need, Then I'm going to close out this issue.

I researched several C static analysis tools, but that all (mostly) want to mark what code was not executed for a specific run of the code, not perform static analysis of what code can never be executed on any run of the code. The idea was that you would have a large test suite to exercise the entirety of the codebase, and code that was not entered during this exercise is dead code. This isn't our use case, as we don't have a test suite for the C code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/amnh/PCG/issues/29?email_source=notifications&email_token=ADG45MUAGPDSHDFSIC5QA3DP6TKVNA5CNFSM4DHFURC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZREFWI#issuecomment-509756121, or mute the thread https://github.com/notifications/unsubscribe-auth/ADG45MRDLKFKHMNKITEQL23P6TKVNANCNFSM4DHFURCQ.