I was only trying to use gnu-indent in order to match drmortalwombats's style, but it didn't work out.There are many "standards", gnu just happens to be one of them, you use ".indent" while most of the people I know instead of "editor config" files.
I always try to match the style of any project - but it turns out that it wasn't that simple to get gnu-indent configured for his preferences - and, it has to be said, his style is not consistent throughout the project, anyway, so it wouldn't have worked.
Well, if done properly, adding another systems' support files shouldn't impact anything that was pre-existing. This is the case now with my oric-support branch as it stands right now - and drmortalwombat has already merged my CMake changes, since it immediately results in a working MacOS/Linux build without much fuss.if some modifications are required to support other operating systems or tool chains, that should be a separate commit by itself, something separate from the actual features.
But this is moot, since oric-support will be rebase'd before I do the PR, and hopefully there won't be any further style issues.
Oh, what a boring, pedantic whine. This isn't a branch that is submitted as a PR yet, so stop evaluating it as if it were.So looking at your link I can immediately see things that would be rejected as a review where I work because they are changes that were not necessary:
- The line with "target_link_libraries(${PROJECT_NAME}" has a modified carriage return or white space at the end
This is work in progress, so please don't bother commenting on such administrivia until there is actually a PR ready.
Oh my god, did you even read the code?- The "if (mTargetMachine == TMACH_ATARI)" is now a "else if" and Oric has become the primary if instead
Well, this follows the existing naming conventions, which also uses .PRG (used on multiple platforms as well), and .. this is one of a list of things I'll ask drmortalwombat what he thinks about refactoring anyway, when there is actually some valuable Oric support.Regarding the actual change, I think the WriteTapFile should probably be renamed to something the clearly indicate it's for oric, because in the same way as the "DSK" format is not only used on Oric, so is the .TAP extension (or it could have a parameter to say it's an actual "oric tape").
(The project doesn't use if {}'s properly, fwiw, and there are a few other code smells that would be nice to have fixed after Oric support is added...)
Why don't you code-review the rest of the project and see if drmortalwombat wants your PR with fixes to his use of fopen_s.Regarding fopen_s, I never used it, but as far as I can see it returns an errno, are you sure that file would be set to zero if the open fails?
This is a first pass to get Oric support. There are a hundred things I'd fix about drmortalwombats code (WriteTapFile is based on WritePrgFile). The point is to maintain consistency with the existing code - once Oric support is basically working, and drmortalwombat accepts the PR for Oric support, I'll think about making some other suggestions to his code base. His use of fopen_s is a different issue than Oric support ..
Anyway, back to adding Oric CRT and conio functions ..