Use libc c_char instead of i8 for libc strlen() call

[silwol]

This patch allows build errors like https://buildd.debian.org/status/fetch.php?pkg=rust-core-foundation&arch=arm64&ver=0.6.1-1&stamp=1533301991&raw=0 to go through on architectures that use u8 as c_char.

---

This change is 

[nox]

I'm confused why this is built at all on Debian, given it's a macOS-specific crate.

[silwol]

Debian creates packages that contain the source code and serve as build-dependency. It might serve e.g. for cross-compilation in the future. IIRC, the packaging runs the tests with the default feature set, and that fails with i8. I hope you don't mind merging the patch, as it causes no harm, but helps us to maintain one patch less.

[nox]

Sure it causes no harm, but what package are you talking about? What is the crate that you are building on Debian which depends on this one? This code won't work elsewhere than on macOS.

[silwol]

I can't go into all the details, but basically, Debian builds packages containing the source code of a crate. If a crate has a feature, an additional, basically empty, package gets built which contains a dependency on the crate package as well as all crate packages that this feature depends on. So either we would have to patch out the features which depend on other operating systems - which means patching the packages in ways that might cause confusion or lead to difficult to track down errors. Or we choose the other way, which means packaging the source tree down to the leaf crates.
I didn't build this package in first place, but I tracked down the error it threw on some architectures, as seen on https://buildd.debian.org/status/package.php?p=rust-core-foundation which prevents some depending package from being merged from Debian unstable to testing.

[nox]

I can't go into all the details, but basically, Debian builds packages containing the source code of a crate. If a crate has a feature, an additional, basically empty, package gets built which contains a dependency on the crate package as well as all crate packages that this feature depends on. So either we would have to patch out the features which depend on other operating systems - which means patching the packages in ways that might cause confusion or lead to difficult to track down errors. Or we choose the other way, which means packaging the source tree down to the leaf crates.

But what is the purpose of making a package that can't work because it is missing system APIs?

[infinity0]

But what is the purpose of making a package that can't work because it is missing system APIs?

because rust-lang/cargo#5896.

How is this even relevant? core-foundation-rs has a bug, you are justifying not fixing it because you think something else is strange???

[infinity0]

This PR would close #277 BTW.

[nox]

you are justifying not fixing

I never said anything about not fixing it, I'm just being curious about why this was even discovered by Debian, thanks for linking to that Cargo issue.

[jrmuizel]

@bors-servo r+

[bors-servo]

📌 Commit e2ae28c has been approved by jrmuizel

[bors-servo]

⌛ Testing commit e2ae28c with merge df62de5...

[bors-servo]

☀️ Test successful - status-travis
Approved by: jrmuizel
Pushing df62de5 to master...