Re: Cray style vectors

Terje Mathisen <terje.mathisen@tmsw.no> writes:

Tim Rentsch wrote:
>

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>

Tim Rentsch wrote:
>

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>

[...]
>
int8_t sum(int len, int8_t data[])
{
    int s = 0;
    for (unsigned i = 0 i < len; i++) {
      s += data[i];
    }
    return (int8_t) s;
}

>
The cast in the return statement is superfluous.

>
I am normally writing Rust these days, where UB is far less common,
but casts like this are mandatory.

>
Oh.  I didn't know that about Rust.  Interesting.
>
I'm always somewhat surprised when someone advocates using a cast
for such things, and now more surprised to learn that Rust has
chosen to impose using a cast as part of its language rules.  I

>
I am not _sure_ but I believe Rust will in fact verify that all such
casts are in fact legal, i.e. the data will fit in the target
container.
>
This is of course the total opposite of the C "nuclear option", and
much more like other languages that try to be secure by default.
>

understand that it has the support of community sentiment, but
even so it seems like a poor choice here.  I'm not a big fan of
the new attribute syntax, but a form like
>
     return  [[narrow]] s;
>
looks to be a better way of asking Rust to allow what is a
normally disallowed conversion.  By contrast, using a cast is
overkill.  There is unnecessary redundancy, by specifying a type
in two places, and the risk that they might get out of sync.  And
on general principles requiring a cast violates good security
principles.  If someone needs access to a particular room in a
building, we don't hand over a master key that opens every room
in the building.  If someone needs to read some documents that
have classified materials, we don't give them an access code that
lets them read any sensitive material regardless of whether it's
relevant.  Maybe Rust is different, but in C a cast allows any
conversion that is possible in the language, even the unsafe
ones.  It just seems wrong to use the nuclear option of casting
for every minor infringement.

>
I agree, it Rust did it like C, then it would be very unsafe indeed.
>
I have not checked the generated asm, but I believe that if I write
code like this:
>
//  x:u64
  x = 0x1234567890abcdef;
  let y:u8 = (x & 255) as u8;
>
the compiler will see the mask and realize that the conversion is
safe, so no need to interpose a
>
  cmp x,256
   jae trp_conversion
>
idiom.

Sounds like you and I are on the same page here.

OTOH, I have seen C compilers that insist on such a test at the
end of a fully saturated switch statement, even when the mask in
front should prove that no other values are possible.

Yeah, what's up with that?  Even worse, when each of the branches
has a return statement, sometimes there is a warning saying the
end of the function can be reached without returning a value.
That really annoys me.