Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
size_t_is_usize should default to true #1901
Comments
|
If bindgen does make this change, then it'll cause another API change in downstream projects that were already using bindgen between 0.53 and 0.55 that have not explicitly set |
This addresses the first part of rust-lang#1901. If size_t_is_usize is manually set to false, and bindgen encounters any size_t, then we should also probably test to confirm that size_t is congruent to uintptr_t on the current platform. I'm not sure of the best way to do this check.
If size_t_is_usize is manually set to false, and bindgen encounters any size_t, then we should also probably test to confirm that size_t is congruent to uintptr_t on the current platform. I'm not sure of the best way to do this check. Fixes: rust-lang#1901
Fixes: rust-lang#1901 (see also: rust-lang#1903)
|
I've separated out the idea of doing a check (failing with an error) as a different ticket (#1903), so that this ticket can focus specifically on changing the default. |
In #1671, there is a reasonable argument made that a principled mapping between
size_tandusizeis improper.However, all platforms that i'm aware of do equate the two.
bindgen's defaults since 0.53 mean that any binding that exposes a size_t results in an incompatible API across platforms. That is, if some package
fooexposes a bindgen-derived mapping of a C functionsize_t bar(), thenbarwill have a different signature on x86 (where it returns au32) than on x86_64 (where it returns au64). All downstream code that relies on that function will find itself dealing with the same divergent API across platforms. That's pretty weird and ugly for a typesafe langauge like rust. The behavior before 0.53 meant that the exposed API was congruent across platforms.I think bindgen's default should be what the pre-0.53 behavior was, even though it is not in principle "correct". If we do that (so that
size_t_is_usizedefaults totrue), then if bindgen is handling anysize_ton a platform whereusize≠size_tit could fail and abort. A package that wants to can still setsize_t_is_usize(false)if they want to be able to build on such a platform (and impose the consequent API type churn on their downstream dependencies).