Skip to content

libc::TIOCGWINSZ is not defined for FreeBSD targets #292

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
severen opened this issue May 18, 2016 · 4 comments
Closed

libc::TIOCGWINSZ is not defined for FreeBSD targets #292

severen opened this issue May 18, 2016 · 4 comments

Comments

@severen
Copy link
Contributor

severen commented May 18, 2016

Despite the ioctl call TIOCGWINSZ being available on FreeBSD under the sys/ioctl.h header, it's not exposed in libc when built for FreeBSD targets.

If this isn't intentional, I was wondering if maybe it could be add for FreeBSD targets, as this is a blocking issue for a project I'm working on.

Compiling and running the following on FreeBSD should prove that TIOCGWINSZ is available on FreeBSD:

#include <stdio.h>
#include <sys/ioctl.h>

int main(int argc, char **argv) {
    struct winsize sz;

    ioctl(0, TIOCGWINSZ, &sz);
    printf("Screen width: %i  Screen height: %i\n", sz.ws_col, sz.ws_row);
    return 0;
}
@severen severen changed the title libc::TIOCGWINSZ is not defined for x86_64-unknown-freebsd libc::TIOCGWINSZ` is not defined for FreeBSD targets May 18, 2016
@severen severen changed the title libc::TIOCGWINSZ` is not defined for FreeBSD targets libc::TIOCGWINSZ is not defined for FreeBSD targets May 18, 2016
@alexcrichton
Copy link
Member

Ah constants are just added piecemeal to libc rather than all at once to all platforms typically. There's no particular reason this was left out, and we'd be more than willing to have it! Want to send a PR?

@severen
Copy link
Contributor Author

severen commented May 18, 2016

I'd love to submit a PR, but I'm completely new to syscalls/ioctl, etc. as well as developing for FreeBSD.

I needed TIOCGWINSZ as I was updating my Linux code to support BSD and OS X, so I'm not really focusing specifically on FreeBSD.

My current understanding is that the ioctl calls are manually defined by figuring out their request code. Unfortunately I have no idea how exactly I'm supposed to find the code for FreeBSD. On Linux it's dead easy, as there's a convenient list here. I suppose it may be somewhere in the source.

Perhaps you could give me some pointers? I'm usually in IRC around 6-12 PM NZST during the week.

@alexcrichton
Copy link
Member

Ah no worries! I've typically just dug around in the FreeBSD headers to look for these values (I don't have a machine on hand). Our linux-cross docker image should have a bunch of headers for cross compilation, and you may be able to poke around the sources downloaded here perhaps?

@severen
Copy link
Contributor Author

severen commented May 19, 2016

After some thinking I realised I could just do this:

#include <sys/ioctl.h>
#include <stdio.h>
#include <unistd.h>

int main (int argc, char **argv) {
    // Prints: "Code: 0x40087468"
    printf("Code: 0x%04lx\n", TIOCGWINSZ);
    return 0;
}

Since I've now got the right request code, I'll get to adding it to libc.

bors added a commit that referenced this issue May 19, 2016
Add the TIOCGWINSZ and TIOCSWINSZ constants

I've added the `TIOCGWINSZ` and `TIOCSWINSZ` constants/ioctl control codes. I wasn't quite sure where to put them, so hopefully they're in the right place.

As of now it's set to compile on 'FreeBSD-like' platforms, so it will compile on both FreeBSD *and* DragonflyBSD. I've only tested it on FreeBSD though, but it should also work on DragonflyBSD AFAIK.

Fixes #292.
bors added a commit that referenced this issue May 19, 2016
Add the TIOCGWINSZ and TIOCSWINSZ constants

I've added the `TIOCGWINSZ` and `TIOCSWINSZ` constants/ioctl control codes. I wasn't quite sure where to put them, so hopefully they're in the right place.

As of now it's set to compile on 'FreeBSD-like' platforms, so it will compile on both FreeBSD *and* DragonflyBSD. I've only tested it on FreeBSD though, but it should also work on DragonflyBSD AFAIK.

Fixes #292.
@bors bors closed this as completed in #293 May 20, 2016
Susurrus pushed a commit to Susurrus/libc that referenced this issue Mar 26, 2017
…=kamalmarhubi

testing: increase stability by removing thread parallelism

Currently, several of the tests are failing intermittently.  After
some research it appears that these failures only occur when thread
parallelism is enabled (as is the case by default).  To test, I just
ran the failing tests over and over.  I would consistently see errors
when running the following:

    $ while true; do target/debug/test-7ec4d9681e812f6a; done

When I forced single threaded execution, I no longer saw failures:

    $ while true; do RUST_TEST_THREADS=1 target/debug/test-7ec4d9681e812f6a; done

I was mostly looking at the test_unistd failures which make calls out
to fork() and then make subsequent calls to wait().  In that case there
is one parent and the wait() called could (and frequently does) get some
random child pid back because it just happened to terminate.  That is
why when one of the test fails so does the other one.

I couldn't think of an obvious fix other than preventing thread
parallelism in the short term.  The tests still run very quickly.

nix-rust/nix#251

Signed-off-by: Paul Osborne <[email protected]>
Susurrus pushed a commit to Susurrus/libc that referenced this issue Mar 26, 2017
After rust-lang#292 was merged, this flakiness remained. I observe it only on
Darwin, hence the targetted disabling until there's been more
investigation.
Susurrus pushed a commit to Susurrus/libc that referenced this issue Mar 26, 2017
tests: Disable test_sigwait on apple platforms

After rust-lang#292 was merged, this flakiness remained. I observe it only on
Darwin, hence the targetted disabling until there's been more
investigation.
danielverkamp pushed a commit to danielverkamp/libc that referenced this issue Apr 28, 2020
This is primarily doing to avoid falling into a portability trap by accident,
and in general makes the vendor types (on x86) going towards as minimal as they
can be. Along the way some tests were cleaned up which were still using the
portable types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants