Use a portable isize definition.

[Prabhuk]

Remove platform specific headers which were included for ssize_t and use intptr_t instead to prevent failures in baremetal builds.

[dtolnay]

Do you have an idea how to preserve this assertion in the cases that ssize_t is available?

cxx/src/cxx.cc

Lines 445 to 448 in cd508fc

	static_assert(sizeof(rust::isize) == sizeof(std::intptr_t),
	"unsupported ssize_t size");
	static_assert(alignof(rust::isize) == alignof(std::intptr_t),
	"unsupported ssize_t alignment");

[frobtech]

Do you have an idea how to preserve this assertion in the cases that ssize_t is available?

cxx/src/cxx.cc

Lines 445 to 448 in cd508fc

	static_assert(sizeof(rust::isize) == sizeof(std::intptr_t),
	"unsupported ssize_t size");
	static_assert(alignof(rust::isize) == alignof(std::intptr_t),
	"unsupported ssize_t alignment");

I'm not clear on what you're looking for here. Those assertions are now tautologically true since the type is just an alias.

It's not clear to me how the POSIX ssize_t type is relevant to this code at all. It's not part of the C or C++ language specification. It's a common and important type in a particular C API that may be common for people to use via the FFI. But it's not clear what's special about the POSIX C APIs in this regard vs any other C API someone might be concerned with. Every C API will define its own types, not uncommonly including typedefs for integer types used for particular semantic purposes. AFAICT your crate is intended to be entirely generic to the C & C++ languages and the Rust language, not to directly encode specific API knowledge outside the language standards per se (which include their standard libraries).

I'm guessing that the scenarios of concern are APIs where you want a C signature using ssize_t to yield a Rust signature using isize. ISTM that such cases would be more ideally served by emitting static_asserts that each particular API type in question (such as ssize_t) matches the crate's chosen C++ equivalent for its chosen Rust type (such as std::intptr_t for Rust isize) alongside the emitted C++ declarations. That is more general, more thorough, and more clearly aligned with the precise constraints intended to be verified, than any single central check of some particular C/C++ API's types.

Now, practically speaking, if what you really do want is to do some assertions about ssize_t in particular when building for an environment that supports (at least a subset of) POSIX APIs, then I can offer some advice about that (though I'd dearly like to understand exactly why that is really what you want to do).

What I think is canonical and best practice here is to use empirical build-time checks about what APIs are available. I'm not very familiar with Rust crates and how things are done there. In builds using autoconf or cmake, it's very common to wire up configure-time checks for whether a particular C/C++ header file is available. (There are also easy canned checking features specifically for types existing IIRC.) In this case, I think it's probably sufficient to just presume that if <sys/types.h> exists it defines ssize_t (though maybe not, if sufficiently old POSIXish environments, or especially poor POSIX subsets in non-POSIX environments, are supported).

If you don't mind relying on a feature that wasn't standard in C++ until C++17, or on one that is available only in non-ancient versions of common compilers like GCC and Clang in pre-17 C++ modes, then you could just use #if __has_include(<sys/types.h>) as the equivalent to a configure-time check for the presence of the header. (It's not quite as robust in the weirdest corners, since the autoconf/cmake style of checks will treat any sort of errors from including the header on its own as equivalent to its absence, while __has_include won't prevent you from using an existing header that, for whatever reasons, doesn't actually work in practice.)

[kesyog]

@dtolnay mind taking another look at this and the above comment?