Skip to content
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

Missing POSIX confstr and _CS_* symbols on Linux. #3767

Closed
jgarzik opened this issue Jul 7, 2024 · 7 comments · Fixed by #3771
Closed

Missing POSIX confstr and _CS_* symbols on Linux. #3767

jgarzik opened this issue Jul 7, 2024 · 7 comments · Fixed by #3771
Labels
C-API-request Category: API request

Comments

@jgarzik
Copy link

jgarzik commented Jul 7, 2024

Apple Darwin provides the POSIX standard confstr(3) function and associated _CS_* symbols. Tested on Darwin and is working.

Requesting the same for Linux.

Quoting src/unix/bsd/apple/mod.rs:

// `confstr` keys (only the values guaranteed by `man confstr`).
pub const _CS_PATH: ::c_int = 1;
pub const _CS_DARWIN_USER_DIR: ::c_int = 65536;
pub const _CS_DARWIN_USER_TEMP_DIR: ::c_int = 65537;
pub const _CS_DARWIN_USER_CACHE_DIR: ::c_int = 65538;
...
    #[cfg_attr(
        all(target_os = "macos", target_arch = "x86"),
        link_name = "confstr$UNIX2003"
    )]
    pub fn confstr(name: ::c_int, buf: *mut ::c_char, len: ::size_t) -> ::size_t

The Linux version for this crate should be very similar. The Linux man page for confstr(3) also helpfully lists the few key _CS_* symbols that the developer should expect to be available:

       _CS_GNU_LIBC_VERSION (GNU C library only; since glibc 2.3.2)
       _CS_GNU_LIBPTHREAD_VERSION (GNU C library only; since glibc 2.3.2)
       _CS_PATH
@jgarzik jgarzik added the C-API-request Category: API request label Jul 7, 2024
@jgarzik jgarzik changed the title Missing confstr and _CS_* symbols on Linux. Missing POSIX confstr and _CS_* symbols on Linux. Jul 7, 2024
@devnexen
Copy link
Contributor

Would you be pleased to create a PR ?

@jgarzik
Copy link
Author

jgarzik commented Jul 11, 2024

@devnexen I gave it a shot with #3771, but I do not understand why the arm test is failing, so I'm a bit stuck.

@magicant
Copy link
Contributor

For the libc-0.2 branch, #3612 is awaiting review.

@jgarzik
Copy link
Author

jgarzik commented Jul 13, 2024

For the libc-0.2 branch, #3612 is awaiting review.

Would it make sense to push to the main branch first, then backport once merged?

(I'm not familiar with this project's upstreaming flows)

@magicant
Copy link
Contributor

I opened #3612 in the hope that 0.2.x would get released sooner than 1.0. If 1.0 is coming out soon, I'd retarget for the main branch. Any plans for future releases?

@jgarzik
Copy link
Author

jgarzik commented Jul 16, 2024

I opened #3612 in the hope that 0.2.x would get released sooner than 1.0. If 1.0 is coming out soon, I'd retarget for the main branch. Any plans for future releases?

Maybe I'm an old greybeard, but usually the norm is to post an upstream patch first, then backport to a branch once merged upstream, regardless of date when the next upstream release will come?

That way, the open source upstraming norm, nothing is lost when users transition from 0.2.x to 1.0.x.

@magicant
Copy link
Contributor

I just followed the plan written in #3248. Not sure if the plan is still effective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-API-request Category: API request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants