Hi there,
I’m a new contributor with work in progress to address some Haiku code hygiene as part of maturing the arm64 port. My current milestones are getting it to build and run inside QEMU aarch64 on an Apple Silicon Mac. Building works, running it in QEMU is still flakey. Toward that end, I’m currently addressing some basic git repo cleanliness:
- pre-commit hooks to enforce the following policies:
- strip trailing whitespaces except on .md files.
- checking that non-binary executables, e.g. bash scripts start with a proper shebang.
- check for files that contain merge conflicts.
- check for bad symlinks
- normalize EOLs to always be LFs. Not CRLF, not CR.
- ensure all files end in EOL and only an EOL.
- optionally check that filenames are distinct, even on case-insensitive filenames. I’m aware the current naming violates that criteria, but it’s a major annoyance and knowing the extent of the problem is useful for future remediation.
- add a
.gitattributesfile to explicitly set file handling.- use
* text=auto eol=lf, which converts line endings to LF on checkout for anything git decides is a text file. - explictly set git’s binary attribute on files with certain extensions, e.g. *.gif, *.jpg, *.rsrc, *.pfb, etc. so git doesn’t do EOL conversions or produce textual diffs for them.
- use
- add some settings in
.editorconfig, which most text editors use.- default character set is
utf-8. - defalt EOL is lf.
- insert final newlines.
- trim trailing whitespace.
- Makefiles use tabs.
- markdown files preserve trailing whitespace.
- default character set is
The pre-commit hooks run ad hoc or as part of commits as linting. Trivial to add them to a CI/CD system. Easy enough to also run clang-tidy, ShellCheck, etc.
For C files, the indenting is currently tabs with 4 stops. Is this true for all other file types? Or should the default be 2 spaces instead of tabs? I didn’t see anything in the style guide. I’m tabs vs spaces agnostic so long as it’s consistent. Except for Makefiles, which require tabs.
My argument for consistent LF EOLs is that, even on Windows, modern editors respect it and it’s standard behavior for Linux and MacOS. Same with tools expecting all files end with an empty line. Extraneous invisibles and whitespace at line ends is annoying for several reasons, usually for diffs. Diff clutter, merge conflicts, expecting the ‘End’ key to jump to the end of line. I ran pre-commit to fix the trailing whitespace on a local branch and there was a LOT of it: 3732 files. An .editorconfig is a great preventitive measure.
I’ve also been fixing the easier compiler errors, using C++17 as the minimum required standard. IMHO, it’s not worth the misery of #ifdef’s and macros to support older dialects, especially with features like noexcept as part of the type system, __has_include, standard attributes for unused arguments and parameters instead of __attribute__((__unused__). The warnings I’ve been getting out of the way:
- Unused arguments, variables, etc. with the
[[maybe_unused]]attribute. sprintftosnprintfto prevent buffer overflows.reinterpret_castto replace C-style casts. That quiets warnings about alignment on aarch64. Also makes it easy to grep for bugs falling out of ARM’s 8-byte stack alignment.
Also found a subtle defect building on MacOS aarch64. Variadic arguments are passed on the stack instead of registers, which causes runtime bugs with mapping open(…) to _haiku_build_open(), the latter having a fixed number of arguments. It’s non-comformant to the C standard to assume that behavior.
Anyway, let me know your thoughts.
