Skip to content

Replace str::sbuf with *ctypes::c_char #1715

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.

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

Closed
brson opened this issue Jan 31, 2012 · 9 comments
Closed

Replace str::sbuf with *ctypes::c_char #1715

brson opened this issue Jan 31, 2012 · 9 comments
Assignees
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Jan 31, 2012

sbuf is mostly used for C interop. Interestingly, we define sbuf as *u8 and usually talk about strings as arrays of u8, but C char is a signed value. It probably doesn't make any difference.

@marijnh
Copy link
Contributor

marijnh commented Jan 31, 2012

See also #1672

@graydon
Copy link
Contributor

graydon commented Feb 15, 2012

C char is actually a signed-or-unsigned value depending on platform. C int and unsigned are the signed/unsigned pair, likewise short and unsigned short. But char is the weird one. There are three of them: char, unsigned char and signed char. Really:

ISO/IEC 9899:1999, 6.2.5.15 (p. 49)
The three types char, signed char, and unsigned char are collectively called
the character types. The implementation shall define char to have the same range,
representation, and behavior as either signed char or unsigned char.

@graydon
Copy link
Contributor

graydon commented Feb 15, 2012

Needless to say, I think this is such utter nonsense that it has no place re-infecting our type system, and I'm happy to encapsulate the madness in the ctypes module!

@brson
Copy link
Contributor Author

brson commented Feb 15, 2012

graydon, I can't tell where you fall on getting rid of sbuf. I now think we have two use cases - treating a string as a byte buffer, and interop with C. So I think we should get rid of str::sbuf, make str::as_buf use a *u8 buffer, and add a new str::as_cstr that does the exact same thing, but typed as a *ctypes::c_char buffer. Also str::from_cstr/from_cstr_len take *c_char and we get two new str::from_buf/from_buf_len functions for *u8.

@marijnh
Copy link
Contributor

marijnh commented Feb 15, 2012

Can someone show me any (sane) code where it is important for the signedness of characters in Rust aligns with that of C? It seems that just being able to assume unsignedness (on the Rust side) makes thing easier. You don't want to conditionalize all code that works with >127 char values on some obscure flag.

@brson
Copy link
Contributor Author

brson commented Mar 12, 2012

I'm in favor of defining c_char as u8.

@ghost ghost assigned brson Mar 14, 2012
@brson
Copy link
Contributor Author

brson commented Mar 14, 2012

This is what i intend to do:

  1. Define c_char correctly for the platform
  2. Eliminate sbuf and replace it with *u8 everywhere
  3. Add str::as_c_str that does the same as as_buf but casts to *c_char
  4. Convert callers to the new function as appropriate

@brson
Copy link
Contributor Author

brson commented Mar 14, 2012

Also, modifying str::from_cstr, etc. to use *c_char and adding companion from_buf methods

@brson
Copy link
Contributor Author

brson commented Mar 15, 2012

Done.

@brson brson closed this as completed Mar 15, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

3 participants