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

Clarify the semantics of type cast #16963

Closed
nodakai opened this issue Sep 3, 2014 · 3 comments
Closed

Clarify the semantics of type cast #16963

nodakai opened this issue Sep 3, 2014 · 3 comments

Comments

@nodakai
Copy link
Contributor

nodakai commented Sep 3, 2014

The current spec is not clear about such expressions as -1i32 as uint as i32 == -1i32 hold or not.

http://doc.rust-lang.org/rust.html#type-cast-expressions

7.2.11.5 Type cast expressions

A type cast expression is denoted with the binary operator as.

Executing an as expression casts the value on the left-hand side to the type on the right-hand side.

A numeric value can be cast to any numeric type. A raw pointer value can be cast to or from any integral type or raw pointer type. Any other cast is unsupported and will fail to compile.

An example of an as expression:

fn avg(v: &[f64]) -> f64 {
  let sum: f64 = sum(v);
  let sz: f64 = len(v) as f64;
  return sum / sz;
}

Cf: Java8 spec http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.5

Background: I began to worry about this when I noticed some codes in libnative cast os::errno() into uint though POSIX defines errno to be a C int variable (on Linux, none of E*** actually have a negative value.)

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html

The symbol errno shall expand to a modifiable lvalue of type int.

@nodakai
Copy link
Contributor Author

nodakai commented Sep 5, 2014

Now I see that number casts are handled by trans_imm_cast() here

Basically they are translated into LLVMBuildSExtOrBitCast etc. which wrap llvm::CastInst

Seems like they are all implemented in the "least surprising" way for C programmers, but still, they should be rigorously defined/documented in the language reference manual because they are fundamental in a serious system programming.

@mahkoh
Copy link
Contributor

mahkoh commented Sep 5, 2014

I can imagine that this depends on the hardware. Apart from that I think the following two rules describe value as new_type:

  1. If the new type is unsigned, the value is converted by repeatedly
    adding or subtracting one more than the maximum value that can be
    represented in the new type until the value is in the range of the new type.
  2. Otherwise the value is converted by repeatedly adding or subtracting twice
    the minimum value that can be represented in the new type until the value is
    in the range of the new type.

The first paragraph comes from the C standard, the second one is implementation defined in C.

@steveklabnik
Copy link
Member

This is effectively part of #16676, so i'm giving it a close, as we'll address that as part of that.

bors added a commit to rust-lang-ci/rust that referenced this issue Mar 31, 2024
fix: ADT hover considering only type or const len not lifetimes

I feel like test doesn't do much. Please suggest if I should improve it?

Fixes rust-lang#16963
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

3 participants