Hi Aaron, list,
Post by Aaron Muir Hamilton
Some of these misleading indentation errors also look like genuine bugs.
Here's one gem from backends/genesys_gl847.c which turned into a
660 while (val8 & REG41_FEBUSY);
662 usleep (10000);
663 status = sanei_genesys_get_status (dev, &val8);
Pay close attention to the semicolons.
Things like this is why I prefer to address the compiler warnings one at
a time and ask for feedback where not sure what to do.
Post by Aaron Muir Hamilton
As an aside, this is probably why the 1TBS is superiour to GNU-style.
Not familiar with 1TBS, so I looked it up
OK, got it. Fine with me, though most of my own C/C++ code uses GNU.
We all have our preferences and I am not going to step on people's toes
trying to enforce a "one true style" for all of sane-backends. Backend
maintainers can use whatever works for them in those files that make up
their backends. All I would like to ask is to use whatever they prefer
consistently throughout a file.
If the file includes hints for common editors that's great but that is
typically limited to emacs and vim. Adding an EditorConfig entry
would be better as that ought to work for even more editors and IDEs.
What I would like to apply throughout though is
- UTF-8 encoding everywhere
- no trailing whitespace at the end of line
- no trailing empty lines are the end of file
- new line at end of file
That shouldn't be too controversial but I'll stay away from the coding
style (and tab versus spaces) wars ;-)
Post by Aaron Muir Hamilton Post by Olaf Meeuwissen
# Never even mind Fedora 26 and Debian 9 on the horizon which'll trigger
# a small "tsunami" of compiler warning fixes and autotools updates ...
It's ugly work, but maybe it's time we normalize the formatting in some
of the files (especially ones which are abandoned-ish and don't have
open patches). A lot of the compiler warnings I see (I run Arch Linux,
so I'm on bleeding-edge-ish GCC most of the time) are things like
misleading indentation warnings. We don't need to invest in any
infrastructure for formatting IMHO, we could just do a once-over with
clang-format on some of the files.
As mentioned above, we all have our coding style preferences and some of
the developers may be more outspoken than others. Since I like to keep
as many of them around as possible, I prefer to tread carefully with a
blanket re-indent of (some of the) code files. If the indenting is more
or less (more rather than less) consistent, I don't see any need to redo
We have a number of builds among which Fedora 25 should give results
close-ish to what you see. Checkout out one of the recent logs.
I try to keep the ci-envs up-to-date with *stable* releases, so
Fedora 26 (and Debian 9?) should be just around the corner.
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
sane-devel mailing list: email@example.com
Unsubscribe: Send mail with subject "unsubscribe your_password"