Replace C types with Rust types in std, closes #7313

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.

[fhahn]

I've started working on a patch for #7313 . So far I tried to replace C types in src/libstd/unstable/* and related files.

So far, I have two questions. Is there a convention for passing pointers around in std as Rust types? Sometimes pointers are passed around as *c_char (which seems to be an *i8), *c_void or *u8, which leads to a lot of casts. E.g: exchange_malloc used to return a *c_char but the function in turn only calls malloc_raw which returns a *c_void.
Is there a specific reason for this?

The second question is about CString and related functions like with_c_str. At the moment these functions use *c_char*. Should I replace it with *u8 or keep it, because it's an wrapper around classical C strings?

[brson]

Thanks for working on this cleanup.

There's no specific reason for all the runtime functions returning weird combinations of pointer types, it's just the legacy of refactoring in various ways. Ideally, they all agree on the types and there are no casts.

CString should probably keep using c_char.

I think it's debatable whether the various logging and other runtime functions that deal in c strings should use *c_char or *u8 or some other typedef. This is all internal details so it doesn't matter too much. Ultimately we're probably going to want to be able to compile out std::libc in environments that don't have it, so the less we depend on it the better.

[fhahn]

So should various functions pass C strings around as u8? *c_str functions are used in a lot of places.

When working on this issue, another idea came to my mind. There probably are a couple of unnecessary type casts in the rust source code and while working on this issue, I accidentally introduced another. Would a lint for unnecessary type casts be useful in generel?

[brson]

@fhahn Public API's that deal with C strings should definitely use *c_char. The compiler interface (lang items like start and probably the failure stuff) should definitely not use *c_char. Other functions I'm less sure of but can probably be inferred from whether they are called form other functions that use *c_char.

[brson]

A lint for unnecessary type casts sounds useful, but I guess we won't know until we try.

[fhahn]

Bors failed to test this PR, because it could not be merged. I've rebased pull request to the current master.

[emberian]

@fhahn an "unneeded cast" lint sounds great.

[fhahn]

@cmr not sure if you already saw #11135, my first version of a lint for unnecessary casts. The main problem atm is handling macros which use casts.

[fhahn]

There was a missing type cast on Windows, which failed the build bot. It should be fixed now, but unfortunately I won't have a Windows (or OS X) installation handy over the next couple of days, to test the patch on other platforms than Linux.

[fhahn]

@brson no worries, I didn't have much time to work on this patch the last couple of days. Before this patch gets merged, I'd like to clear up a few points:

• at the moment I'm not really sure if I should use *u8 or *Void instead of *c_void. I'd like to keep my patch consistent with the other parts (in the existing source sometimes *Void is used and sometimes *u8).
• I think I made good progress with pushing libc types down, expect for pipes and processes. The problem with pipes is, that they store 2 file descriptors internally and are used in combination with the pre defined fds in libc, like stdout. If file descriptors of pipes are stored as a Rust type, then comparing with this predefined fds would require more additional typecasts or file descriptors as a Rust type.

[adrientetar]

That should probably be uint, since 32-bit wants u32.

[fhahn]

I've changed the type to uint and added a cast to size_t at the cast.

[fhahn]

I've updated the commit. It compiles on 64- and 32-bit linux.

[fhahn]

I've updated the commit again, it should compile on win32 now.

[sfackler]

@fhahn needs a rebase.

[fhahn]

@sfackler I'll look into it tomorrow. I managed to compile this patch on windows (win7 32 bit) without errors today, but 2 run-pass tests fail at the moment.

Following code compiles on Windows, but fails when building libstd in stage 1:

let nArgs: uint = 0;
let lpCmdLine = unsafe { GetCommandLineW() };
let szArgList = unsafe { CommandLineToArgvW(lpCmdLine, (&mut (nArgs as c_int)) as *mut c_int) };

I've reverted this change and I'm using the old code (with two c_int variables): https://github.com/mozilla/rust/blob/master/src/libstd/os.rs#L740

[adrientetar]

Needs a snapshot?

[alexcrichton]

I think this file came back from the dead!

[alexcrichton]

With the extra file removed, we can give this another go-through with bors.

[fhahn]

I've removed the file again and squashed everything in one commit. I think another try with bors would be good.