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.

Sign up for GitHub

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

Jump to bottom

Specify that bool is compatible with the _Bool C type. #954

Closed
wants to merge 2 commits into from
Closed

Specify that bool is compatible with the _Bool C type. #954

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a034e45
add cbool rfc
mahkoh Mar 8, 2015
c95bba1
fixup
mahkoh Mar 14, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions text/0000-cbool.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
- Feature Name: cbool
- Start Date: Mon Mar 9 00:16:53 CET 2015
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

Specify that `bool` is compatible with the `_Bool` C type.

# Motivation

You cannot safely call ffi functions with boolean arguments without a compatible type.

# Detailed design

Specify that `bool` is compatible with the `_Bool` C type and inform the compiler that `bool` is ffi safe.

# Drawbacks

None right now. This should be a no-op on all supported platforms.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about arbitrary unsupported platforms? This proposal has the ability to box us into a suboptimal corner, by being beholden to whatever quirks C might have.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsupported platforms are not supported, hence we're not beholden to do anything on those platforms, unless I misunderstand your concern.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are only unsupported now. If/when we gain support for them we will have to guarantee that bool acts like _Bool on those platforms too, so we need to plan ahead.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. It seems unlikely to me that there will be any platforms where _Bool is different than our bool (especially considering that we will only ever target platforms LLVM supports, which means there is some degree of sanity), but I guess it is possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the plan for platforms that don't use two's complement? If there is no such plan, then why would you worry more about the representation of bool than the representation of u8?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also, I have no idea if _Bool is one byte on all supported platforms, so bool still may not match _Bool even with that property.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The premise of this argument is pretty ridiculous: "We know better than the hardware developers how to represent a boolean value on their hardware."

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not ridiculous: the C _Bool type on some platforms may have historical constraints that don't apply to Rust. In any case, the precise representation of C types is usually chosen by the compiler, not the hardware.

A minimum improvement that would help assuage my concerns would be quoting the C standard's definition of _Bool in the RFC.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case, the precise representation of C types is usually chosen by the compiler, not the hardware.

That's wrong. The representation of _Bool is part of the ABI and should be (for all hardware developed after C99) defined by the hardware vendor. E.g.

http://www.x86-64.org/documentation/abi.pdf page 12
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf page 26

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That information should be in the RFC.


# Alternatives

Define `_Bool` as a platform dependent integer type. This is unsafe because the behavior is supposedly undefined if you pass a value other than 0 or 1 to such a function.

# Unresolved questions

None.