* fix: __attribute__(__printf__) warnings
* fix: implicit fallthrough warning
* fixup! fix: implicit fallthrough warning
* fix: disable warnings for 3rd party code
Since we want to leave upstream code as-is
* fixup! fix: disable warnings for 3rd party code
* fixup! fix: disable warnings for 3rd party code
* silence spurious alignment warning
Xrefs
Discussion: https://stackoverflow.com/a/35554349
Macro inspiration: 90ac46f710/f/src/util/util_safealign.h (_35)
* fixup! fix: disable warnings for 3rd party code
* fixup! fix: implicit fallthrough warning
* make uncrustify happy
* remove uncrustify-test.sh
that's probably off-topic for this PR
* fixup! fix: __attribute__(__printf__) warnings
* Update libtransmission/CMakeLists.txt
Co-Authored-By: ckerr <ckerr@github.com>
* fixup! silence spurious alignment warning
* use -w for DISABLE_WARNINGS in Clang
* refactor: fix libtransmission deprecation warnings
* fix: pthread_create's start_routine's return value
This was defined as `void` on non-Windows but should have been `void*`
* chore: uncrustify
* fix: add DISABLE_WARNINGS option for SunPro Studio
* fix "unused in lambda capture" warnings by clang++
* fix 'increases required alignment' warning
Caused from storing int16_t's in a char array.
* fix net.c 'increases required alignment' warning
The code passes in a `struct sockaddr_storage*` which is a padded struct
large enough for the necessary alignment. Unfortunately it was recast as
a `struct sockaddr*` which has less padding and a smaller alignment. The
warning occrred because of these differing alignments.
* make building quieter so warnings are more visible
* fixup! fix 'increases required alignment' warning
* Fix -Wcast-function-type warnings in GTK+ app code
https://gitlab.gnome.org/GNOME/gnome-terminal/issues/96 talks about both
the issue and its solution.
GCC 8's -Wcast-function-type, enabled by -Wextra, is problematic in glib
applications because it's idiomatic there to recast function signatures,
e.g. `g_slist_free(list, (GFunc)g_free, NULL);`.
Disabling the warning with pragmas causes "unrecognized pragma" warnings
on clang and older versions of gcc, and disabling the warning could miss
actual bugs. GCC defines `void (*)(void)` as a special case that matches
anything so we can silence warnings by double-casting through GCallback.
In the previous example, the warning is silenced by changing the code to
read `g_slist_free(list, (GFunc)(GCallback)g_free, NULL);`).
* fixup! fix "unused in lambda capture" warnings by clang++
* fixup! fix "unused in lambda capture" warnings by clang++
* fix two more libtransmission compiler warnings
* fix: in watchdir, use TR_ENABLE_ASSERTS not NDEBUG
* MISRA C++:2008, 8-0-1 - An init-declarator-list or a member-declarator-list
shall consist of a single init-declarator or member-declarator respectively
* CERT, DCL52-J. - Do not declare more than one variable per declaration
* CERT, DCL04-C. - Do not declare more than one variable per declaration
Assignments explicitly enclosed in parentheses are ignored.
* MISRA C:2004, 13.1 - Assignment operators shall not be used in expressions
that yield a Boolean value
* MISRA C++:2008, 6-2-1 - Assignment operators shall not be used in
sub-expressions
* MISRA C:2012, 13.4 - The result of an assignment operator should not be used
* MITRE, CWE-481 - Assigning instead of Comparing
* CERT, EXP45-C. - Do not perform assignments in selection statements
* CERT, EXP51-J. - Do not perform assignments in conditional expressions
* MISRA C++:2008, 2-13-4 - Literal suffixes shall be upper case
* MISRA C:2012, 7.3 - The lowercase character "l" shall not be used in a
literal suffix
* CERT DCL16-C. - Use "L," not "l," to indicate a long value
* CERT, DCL50-J. - Use visually distinct identifiers
The -symbolic icon variant (if available) is used in the GNOME top bar,
and when the high contrast theme is in use. This icon was created by
Jakub Steiner, and comes from the gnome-icons repository:
https://github.com/gnome-design-team/gnome-icons/blob/master/apps-symbolic/Adwaita/scalable/apps/transmission-symbolic.svghttps://bugzilla.redhat.com/show_bug.cgi?id=1221292
There is some confusion over whether symbolic app icons should be
installed to icons/hicolor/scalable/apps (alongside the regular scalable
icon) or to icons/hicolor/symbolic/apps. On the one hand,
https://wiki.gnome.org/Initiatives/GnomeGoals/HighContrastAppIcons has
this to say:
> […] obtain a suitable symbolic style icon […] and install it to the
> hicolor prefix, the same way you would for the full color variant.
>
> cp myapp-symbolic.svg /usr/share/icons/hicolor/scalable/apps/myapp-symbolic.svg
On the other hand, the Fedora package at
https://src.fedoraproject.org/rpms/transmission/blob/master/f/transmission.spec
ships this icon in icons/hicolor/symbolic/apps:
> # Install the symbolic icon
> mkdir -p %{buildroot}%{_datadir}/icons/hicolor/symbolic/apps
> cp %{SOURCE1} %{buildroot}%{_datadir}/icons/hicolor/symbolic/apps/transmission-symbolic.svg
Anecdotally, icons in scalable/ have minimum size 64×64 on openSUSE, so
symbolic/ is the safer location (given the GNOME top bar uses 32×32
icons). This has the advantage of matching the location used in the
distribution which already ships this file.
https://github.com/transmission/transmission/issues/414
This file was originally written by Richard Hughes, for Fedora, who
proposed it on the Transmission forum here:
https://forum.transmissionbt.com/viewtopic.php?f=3&t=16443
It's used to display a nice description and screenshot in GNOME
Software. The format is documented here:
https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
The <_name/> and <_summary/> fields match the Name= and Comment= fields
in the .desktop file so are already translated.
The screenshot is taken with Transmission 2.92 (14714) on Fedora 25.
It's at one of the sizes recommended by the GNOME Shell Screenshot
Window Sizer extension.
The <update_contact/> is based on the Git history.
This way all the qualifiers (`const`, `volatile`, `mutable`) are grouped
together, e.g. `T const* const x` vs. `const T* const x`. Also helps reading
types right-to-left, e.g. "constant pointer to constant T" vs. "constant
pointer to T which is constant".
There're places where manual intervention is still required as uncrustify
is not ideal (unfortunately), but at least one may rely on it to do the
right thing most of the time (e.g. when sending in a patch).
The style itself is quite different from what we had before but making it
uniform across all the codebase is the key. I also hope that it'll make the
code more readable (YMMV) and less sensitive to further changes.
Charles Kerr
