Prepatory work for supporting -Wthread-safety #1461
Conversation
|
This is prep work for #1419. It is ready for reviewing and merging. |
|
I should add: -Wthread-safety only works fully in C++. Luckily, libusb can be made to (optionally) build as C++ with these modifications. I'm not proposing to change the language libusb builds as by default. I'm proposing it be both valid C and valid C++ so that we can use -Wthread-safety fully. |
| @@ -2467,14 +2467,14 @@ int API_EXPORTED libusb_init_context(libusb_context **ctx, const struct libusb_i | |||
| list_init(&_ctx->open_devs); | |||
|
|
|||
| /* apply default options to all new contexts */ | |||
| for (enum libusb_option option = 0 ; option < LIBUSB_OPTION_MAX ; option++) { | |||
There was a problem hiding this comment.
Why is this? Enum not allowed as counter?
There was a problem hiding this comment.
The old way, two errors:
core.c:2470:26 Cannot initialize a variable of type 'enum libusb_option' with an rvalue of type 'int';
core.c:2470:74 Cannot increment expression of enum type 'enum libusb_option'
| @@ -1666,8 +1668,8 @@ static const struct libusb_interface_descriptor *get_interface_descriptor_by_num | |||
| return NULL; | |||
| } | |||
|
|
|||
| static enum libusb_error get_endpoints (struct libusb_device_handle *dev_handle, uint8_t iface) { | |||
There was a problem hiding this comment.
Why are some function changed to return int instead of enum?
There was a problem hiding this comment.
To pacify the C++ compiler, which is more type strict and does not allow such freewheeling conversions between enums and integers.
There was a problem hiding this comment.
Weird. Does it have to use the C++ compiler. There will be issues if it does because C++ is not a superset of C and some C11 features do not work in C++20.
There was a problem hiding this comment.
Does it have to use the C++ compiler.
-Wthread-safety partly works in C. The big issue is: llvm/llvm-project#20777
C++ is not a superset of C
Indeed, but it mostly is. At least enough for current libusb master.
Again, I'm not wanting to actually switch libusb's build system to C++. I'm only saying it's handy to do so occasionally, to turn -Wthread-safety on occasionally, like as check before cutting a new release.
There was a problem hiding this comment.
Hah, they have been trying to figure out what to do for 10 years?! I see some reasonable options but little movement. There is no technical reason why thread analysis should not work with C.
There was a problem hiding this comment.
Hah, they have been trying to figure out what to do for 10 years?!
Exactly, alas. So to get the full abilities of -Wthread-safety, we need to build libusb as C++ (or start patching clang). Hence this PR. :)
seanm
force-pushed
the
clang-thread-safety-prep
branch
from
3c68a96
to
27de2b4
Compare
seanm
force-pushed
the
clang-thread-safety-prep
branch
from
27de2b4
to
6f307a9
Compare
seanm
force-pushed
the
clang-thread-safety-prep
branch
from
6f307a9
to
7e6a70e
Compare
|
@tormodvolden would be nice to get this merged... I really think libusb could benefit from -Wthread-safety, it has found bugs for us already... |
|
Is this replacing #1419 ? |
seanm
force-pushed
the
clang-thread-safety-prep
branch
from
7e6a70e
to
9ae7460
Compare
… (for C++ compat)
seanm
force-pushed
the
clang-thread-safety-prep
branch
from
9ae7460
to
b65d8eb
Compare
No description provided.