implement ttyname and ttyname_r#1259
Conversation
doy
force-pushed
the
ttyname
branch
8 times, most recently
from
8133e94 to
ad026a1
Compare
|
(i'd really like to see this change, but i don't have access to a dev machine with osx - is there a way forward here?) |
asomers
left a comment
asomers
left a comment
There was a problem hiding this comment.
Apart from the inline comments, this change looks good. As for the OSX test failure, I can't help you because I don't have an OSX machine, either. Try to borrow a friend's if possible. If not, then you might try "debugging-through-travis" at least to see the exact errno, and the output of isatty(fd.as_raw_fd()).
Finally, if all else fails, my belief is that proprietary operating systems are supported on a "best-effort" basis, and you can disable the function on OSX.
| /// function is marked as `unsafe` to reflect that. | ||
| /// | ||
| /// For a threadsafe and non-`unsafe` alternative, see `ttyname_r()`. | ||
| #[inline] |
There was a problem hiding this comment.
Don't use #[inline] for new code. The compiler can figure it out, at least when LTO is enabled.
| return Err(Error::Sys(Errno::last())); | ||
| } | ||
|
|
||
| let nul = buf.iter().position(|c| *c == b'\0').unwrap(); |
There was a problem hiding this comment.
Instead of manually searching for NUL, why not just use CStr::from_ptr? In fact, you should technically be using OsString here instead of CString, because the string comes from the operating system and not from another programming language. So you should declare the buf as a Vec, and then use OsString::from_vec followed by to_string_lossy.
There was a problem hiding this comment.
i think returning a PathBuf is actually better than String here, and using OsString for that makes sense. that does mean that i do have to still search for the nul myself though, since OsString won't do that (it'll just create a string with a bunch of trailing nuls). going through CStr (and then being forced to allocate a copy into a second Vec) doesn't seem worth it to avoid that?
| /// | ||
| /// For a threadsafe and non-`unsafe` alternative, see `ttyname_r()`. | ||
| #[inline] | ||
| pub unsafe fn ttyname(fd: RawFd) -> Result<String> { |
There was a problem hiding this comment.
Is there a good reason why anybody would ever want ttyname? Since the invention of ttyname_r, I think the latter should be used in all cases. If you don't know of a use case where ttyname_r does not suffice, then I'd just as soon we don't bind ttyname at all.
There was a problem hiding this comment.
yeah, good point - i was mainly copying from the ptsname interface, but i agree that it's really not necessary.
|
alright, i'll play around with travis some more. |
doy
force-pushed
the
ttyname
branch
15 times, most recently
from
f3df1e6 to
5a2107c
Compare
|
looks like it was just an issue with the way i was structuring the test - |
|
The powerpc64 build has only been failing for a few days, and it's fixed on Nix's master branch. You'll have to rebase. |
|
done |
|
Merge conflict. |
|
rebased again |
|
test_aio_drop also seems flaky https://travis-ci.org/github/nix-rust/nix/jobs/704771690 |
|
Build succeeded: |
2 participants
this fixes #1204.
i know this at least works on linux, but i'm not super sure about other platforms - happy to add conditionals if it makes sense.