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

Pointer implementation for Rc and Arc should print the address of pointed value #35384

Closed
malbarbo opened this issue Aug 5, 2016 · 4 comments
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@malbarbo
Copy link
Contributor

malbarbo commented Aug 5, 2016

Consider this example:

#![feature(shared, unique)]

use std::ptr::{Shared, Unique};
use std::rc::Rc;
use std::sync::Arc;

fn main() {
    let x = Box::new(10);
    assert_eq!(format!("{:p}", &*x), format!("{:p}", x));

    let a = &mut 10 as *mut _;
    let x = Shared::new(a).unwrap();
    assert_eq!(format!("{:p}", a), format!("{:p}", x));

    let a = &mut 10 as *mut _;
    let x = Unique::new(a).unwrap();
    assert_eq!(format!("{:p}", a), format!("{:p}", x));

    let x = Rc::new(10);
    println!("rc {:p} {:p}", &*x, x);

    let x = Arc::new(10);
    println!("arc {:p} {:p}", &*x, x);
}

the code runs fine but the printed values are different:

rc 0x7f1eefa1e070 0x7f1eefa1e060
arc 0x7f1eefa1e0d0 0x7f1eefa1e0c0

The Pointer implementation for Rc and Arc prints the address of the inner data (RcBox and ArcInner) instead of the address of the stored value. This seems to be inconsistent with the Pointer implementation for Box, Shared and Unique.

If this is a real issue, I can write a patch to fix it.

@apasel422
Copy link
Contributor

It's sort of inconsistent, but also sort of consistent. {Box, Shared, Unique} don't have inner data, so the only thing they could point to is the value.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 25, 2017
@cyplo
Copy link
Contributor

cyplo commented Oct 12, 2017

The example code from OP does not seem to compile now with rustc 1.22.0-nightly (692b94a 2017-10-09) (anymore?). Would that be something that is expected ?

The error:

error[E0277]: the trait bound `std::option::Option<std::ptr::Shared<_>>: std::fmt::Pointer` is not satisfied
  --> main.rs:13:52
   |
13 |     assert_eq!(format!("{:p}", a), format!("{:p}", x));
   |                                                    ^ the trait `std::fmt::Pointer` is not implemented for `std::option::Option<std::ptr::Shared<_>>`
   |
   = note: required by `std::fmt::Pointer::fmt`

@sinkuu
Copy link
Contributor

sinkuu commented Oct 12, 2017

@cyplo Yes, #42959

@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 18, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 18, 2017

I would like a PR to fix this. Whether the strong and weak counts are stored before or after T in memory seems like an implementation detail, and the address of T seems to me a more intuitive behavior for {:p}.

kennytm added a commit to kennytm/rust that referenced this issue Nov 20, 2017
Print the address of the pointed value in Pointer impl for Rc and Arc

Fixes rust-lang#35384
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants