Skip to content
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

Merged
merged 6 commits into from
Nov 15, 2011
Merged

Use stdbool.h when including utypes.h in C code. #12

merged 6 commits into from
Nov 15, 2011

Conversation

jech
Copy link
Contributor

@jech jech commented Feb 18, 2011

No description provided.

@ghazel
Copy link
Contributor

ghazel commented Feb 18, 2011

Does this work on Windows? What if we just switched to ints?

@jech
Copy link
Contributor Author

jech commented Feb 18, 2011

Does this work on Windows?

It certainly does if using a C99 compiler. So I guess the question is whether it works with VS. I have no idea.

What if we just switched to ints?

You mean, in the public API? Yes, that would solve the issue quite nicely.

--jch

@ghazel
Copy link
Contributor

ghazel commented Feb 19, 2011

I can confirm Visual Studio does not have that header.

@jech
Copy link
Contributor Author

jech commented Feb 19, 2011

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

Juliusz Chroboczek and others added 6 commits March 30, 2011 08:06
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.
@blakawk
Copy link

blakawk commented Oct 24, 2011

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).

@ghazel
Copy link
Contributor

ghazel commented Oct 24, 2011

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.

@ghazel ghazel reopened this Oct 24, 2011
@ghazel ghazel merged commit 4be31bb into bittorrent:master Nov 15, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants