hidapi.h: fix API prototype for gcc flag -Wstrict-prototypes #207
No reviewers
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi!207
Loading…
Reference in a new issue
No description provided.
Delete branch "fix-prototype"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
With gcc 10.2.0 and compile flag '-Wstrict-prototypes' the new
APIs in hidapi.h trigger a compile warning:
../hidapi/hidapi.h:481:32: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
481 | HID_API_EXPORT const struct hid_api_version* HID_API_CALL hid_version();
| ^~~~~~~~~~~~~~~
../hidapi/hidapi.h:491:3: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
491 | HID_API_EXPORT const char* HID_API_CALL hid_version_str();
| ^~~~~~~~~~~~~~
To replicate:
./bootstrap
CFLAG=-Wstrict-prototypes ./configure
make
This is an issue for other projects, like OpenOCD, that use hidapi
and compile by default with '-Wstrict-prototypes -Werror'; the
warning above causes compile error while including hidapi.h.
Fix the prototypes by adding 'void' in the empty parameter list.
Signed-off-by: Antonio Borneo borneo.antonio@gmail.com
Can we enable all these warning flags in CI as well that we're fixing so we don't regress?
Yes, it could be good to add more strict check during CI.
With OpenOCD we use
-Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror
not sure if this set covers all needs of hidapi, but tested after this patch does not show any further warning.