Skip to content
Snippets Groups Projects
  1. May 27, 2016
  2. May 25, 2016
  3. May 22, 2016
  4. May 21, 2016
  5. May 20, 2016
  6. May 19, 2016
  7. May 18, 2016
    • bors's avatar
      Auto merge of #289 - fnichol:fix-musl-ioctl-constants, r=alexcrichton · fb5008c0
      bors authored
      Fix ioctl constants for musl target envs.
      
      Heya!
      
      I ran across this issue today while trying to build a portable static binary using the `x86_64-unknown-linux-musl` target. Took a bit of digging to make sure I understood what was going on, and while I may still be off the mark, I believe this is a fix to my issue.
      
      Thanks!!
      
      ----
      
      According to musl's source, the `ioctl` [function signature][musl-ioctl-h] takes an `int` as the request argument (i.e. an `i32`) which is reflected in this crate's [ioctl binding][musl-ioctl-rs]. It looks like when the ioctl constants were added that [glibc's default][glibc-ioctl-h] of a `c_ulong` type was used for the musl values as well, rather than a `c_int` type. This change updates these constants to a `c_int` so that they match the expected function call type.
      
      Here is a minimal reproduction of the issue. Given this Rust program:
      
      ```rust
      extern crate libc;
      
      use libc::{ioctl, winsize, STDOUT_FILENO, TIOCGWINSZ};
      
      fn main() {
          let mut wsize = winsize {
              ws_row: 0,
              ws_col: 0,
              ws_xpixel: 0,
              ws_ypixel: 0,
          };
          unsafe {
              ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
          }
          println!("Sizes: {{ rows: {}, cols: {}, xpixel: {}, ypixel: {} }}",
                   wsize.ws_row,
                   wsize.ws_col,
                   wsize.ws_xpixel,
                   wsize.ws_ypixel);
      }
      ```
      
      When run against the `x86_64-unknwon-linux-gnu` and
      `x86_64-unknown-linux-musl` targets, we see the difference in behavior:
      
      ```
      > cargo clean
      
      > cargo run --target=x86_64-unknown-linux-gnu
         Compiling libc v0.2.11
         Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
           Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
      Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
      
      > cargo clean
      
      > cargo run --target=x86_64-unknown-linux-musl
         Compiling libc v0.2.11
         Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
      src/main.rs:13:30: 13:40 error: mismatched types:
       expected `i32`,
          found `u64` [E0308]
      src/main.rs:13         ioctl(STDOUT_FILENO, TIOCGWINSZ, &mut wsize);
                                                  ^~~~~~~~~~
      src/main.rs:13:30: 13:40 help: run `rustc --explain E0308` to see a detailed explanation
      error: aborting due to previous error
      Could not compile `libc-musl-ioctl`.
      
      To learn more, run the command again with --verbose.
      ```
      
      Working against this fix:
      
      ```
      > cargo clean
      
      > cargo run --target=x86_64-unknown-linux-gnu
          Updating git repository `https://github.com/fnichol/rust-lang-libc.git`
         Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
         Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
           Running `target/x86_64-unknown-linux-gnu/debug/libc-musl-ioctl`
      Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
      
      > cargo clean
      
      > cargo run --target=x86_64-unknown-linux-musl
         Compiling libc v0.2.11 (https://github.com/fnichol/rust-lang-libc.git?branch=fix-musl-ioctl-constants#3285f387)
         Compiling libc-musl-ioctl v0.1.0 (file:///src/libc-musl-ioctl)
           Running `target/x86_64-unknown-linux-musl/debug/libc-musl-ioctl`
      Sizes: { rows: 28, cols: 211, xpixel: 0, ypixel: 0 }
      ```
      
      [musl-ioctl-rs]:
      https://doc.rust-lang.org/libc/x86_64-unknown-linux-musl/libc/fn.ioctl.html
      
      [musl-ioctl-h]:
      https://git.musl-libc.org/cgit/musl/tree/include/sys/ioctl.h
      
      [glibc-ioctl-h]:
      http://bazaar.launchpad.net/~vcs-imports/glibc/master/view/head:/include/sys/ioctl.h
      fb5008c0
  8. May 16, 2016
  9. May 15, 2016
  10. May 14, 2016
    • bors's avatar
      Auto merge of #285 - lemonrock:sysctl, r=alexcrichton · 72519bf4
      bors authored
      Added extensive constants to make use of the BSD's sysctl function.
      
      sysctl usage does differ significantly across the BSDs, and, whilst
      some constants overlap, many do not. It is easier to maintain them
      in separate modules, rather than trying to tease out common definitions.
      72519bf4
  11. May 13, 2016
  12. May 12, 2016
  13. May 11, 2016
  14. May 10, 2016
    • bors's avatar
      Auto merge of #281 - lemonrock:getprogname, r=alexcrichton · 19fd5047
      bors authored
      Getprogname
      
      Added `getprogname()` and `setprogname()` for all BSDs and Solaris (including Mac OS X).
      
      Added `program_invocation_short_name` global, for Linux (glibc and Musl) which is effectively the same thing, and is what compatibility libraries like `libbsd` use to implement `getprogname()`.
      
      Added `__progname` global for Android, which, whilst not quite the same as `getprogname` or `program_invocation_short_name`, is better than using argv[0], as it (a) avoids a common bug with no arguments (b) avoids a common bug with a NULL string in argv[0] and (c) incorporates Android's chosen name for an unknown process.
      19fd5047
    • Raphael Cohn's avatar
      Adding getprogname and setprogname for all BSDs and Solaris. · 893d4d84
      Raphael Cohn authored
      Adding program_invocation_short_name for Linux (Musl and glibc).
      
      Adding __progname for Android. This is a little different, but
      is a safer alternative to using argv[0], which may not exist, and
      includes Android's default application name (currently '<unknown>').
      
      Adding these functions and externs means it is possible for all
      but Windows applications to safely discover their
      name, rather than rely on argv[0] parsing, /proc/self/exe, etc.
      893d4d84
  15. May 08, 2016
  16. May 07, 2016
  17. May 06, 2016
Loading