Skip to content

Add getpgid. #346

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

Merged
merged 1 commit into from
Aug 3, 2016
Merged

Add getpgid. #346

merged 1 commit into from
Aug 3, 2016

Conversation

frewsxcv
Copy link
Member

@frewsxcv frewsxcv commented Aug 3, 2016

Fixes #345.

@frewsxcv
Copy link
Member Author

frewsxcv commented Aug 3, 2016

Nevermind, got rid of setpgrp since there were build issues I don't want to debug right now:

https://travis-ci.org/rust-lang/libc/builds/149457137

@frewsxcv frewsxcv changed the title Add setpgrp and getpgid. Add getpgid. Aug 3, 2016
@frewsxcv
Copy link
Member Author

frewsxcv commented Aug 3, 2016

setpgrp is also apparently legacy.

@alexcrichton alexcrichton merged commit 23b69f3 into rust-lang:master Aug 3, 2016
@alexcrichton
Copy link
Member

THanks!

@frewsxcv frewsxcv deleted the pg branch August 3, 2016 17:19
@frewsxcv frewsxcv restored the pg branch August 4, 2016 13:08
Susurrus pushed a commit to Susurrus/libc that referenced this pull request Mar 26, 2017
Cast function item to function pointer in order to appease compiler.

This is necessary because of compiler changes. For further information
look at rust-lang/rust#19925.

This solves rust-lang#346.

I know that there are other problems with the affected function. We are thinking about how to best pass the arguments to the function and we don't want to define the ffi's ourselves. However, I would like to get the warning out of our tree as soon as possible. We do not need to wait for our polish.
danielverkamp pushed a commit to danielverkamp/libc that referenced this pull request Apr 28, 2020
This commit renames the `is_target_feature_detected!` macro to have different
names depending on the platform. For example:

* `is_x86_feature_detected!`
* `is_arm_feature_detected!`
* `is_aarch64_feature_detected!`
* `is_powerpc64_feature_detected!`

Each macro already has a platform-specific albeit similar interface. Currently,
though, each macro takes a different set of strings so the hope is that like
with the name of the architecture in the module we can signal the dangers of
using the macro in a platform-agnostic context.

One liberty taken with the macro currently though is to on both the x86 and
x86_64 architectures name the macro `is_x86_feature_detected` rather than also
having an `is_x86_64_feature_detected`. This mirrors, however, how all the
intrinsics are named the same on x86/x86_64.
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

Successfully merging this pull request may close these issues.

2 participants