-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use stdbool.h when including utypes.h in C code. #12
Conversation
Does this work on Windows? What if we just switched to ints? |
It certainly does if using a C99 compiler. So I guess the question is whether it works with VS. I have no idea.
You mean, in the public API? Yes, that would solve the issue quite nicely. --jch |
I can confirm Visual Studio does not have that header. |
Okay, so to summarise, the possibilities are: (1) use bool, where bool expands to uint8 in C (change nothing) This is probably portable (C++ bool is 8-bits on all compilers known to me), but breaks any client code that tries to define its own version of bool (including anyone including stdbool.h). (2) use bool, where bool is defined by stdbool.h in C99, and expands to uint8 in C86 This is probably portable (it would take a very stupid compiler designed to make C++ bool and C _Bool incompatible). It breaks client code that tries to define its own version of bool, except in a C99 compiler if the client code does that by including stdbool.h. (3) avoid bool in the public interface, replace it with int throughout This is portable, and allows client code to define its own version of bool. Since it prevents you from using bool in exported functions, it might lead to some minor obfuscation of the C++ code. (4) avoid bool in the public interface, replace it with utp_bool throughout, where utp_bool expands to bool in C++, _Bool in C99, and uint8 in C86. This is probably portable, allows client code to define its own version of bool, and avoids obfuscating the C++ code. Altogether, I'd recommend (3) or (4). It's not urgent (we're using our own tr_bool in Transmission currently), but it should be fixed at some point. --jch |
Within utp.cpp, there's a bunch of assertions that will cause us to crash if monotonic time isn't. While we're in principle already protecting in the cases where non-monotonicity is likely (see the gettimeofday case for generic Unix, for example), this protects for all versions.
Since we're now protecting against non-monotonic time unconditionally, there's no need for additional protection in the gettimeofday case.
Why this pull request is closed ? It's not fixed in master branch, and so clients using stdbool still cannot compile (see for example Transmission open bug https://trac.transmissionbt.com/ticket/4528). |
This was closed due to a Github bug. If the author deletes the fork and creates a new one all the old pull requests will be closed. |
No description provided.