Declaring the API unsafe while keeping the internal safety checks

Declaring the API unsafe while keeping the internal safety checks

I had this idea for some time and I'd like to discuss it to see if it is something reasonable to be proposed for rust to implement or there are other ways around the problem.

Let's say I have a low level function that manipulates the hardware clock using some platform-specific argument. Internally this function will do an unsafe volatile mem write to store value in the register, but this is the only part of the code that is unsafe compiler-wise, whatever else is in there in the function is safe and I want the compiler to warn me if any other unsafe operation happens.

Now, given that this function is actually unsafe in terms of its realtime consequences (it does not do any validation of the input for speed) I want to mark it as unsafe fn and make a safer wrapper for end users, while keeping this for the little subset of users that will need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any other unsafe operation in the body of the function, when what I wanted is just to force users of it to be aware of unsafety via compiler validation.

A safe {} block could have helped me in this case. But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one is unsafe but validated by programmer

I had this idea for some time and I'd like to discuss it to see if it is something reasonable to be proposed for rust to implement or there are other ways around the problem.

Let's say I have a low level function that manipulates the hardware clock using some platform-specific argument. Internally this function will do an unsafe volatile mem write to store value in the register, but this is the only part of the code that is unsafe compiler-wise, whatever else is in there in the function is safe and I want the compiler to warn me if any other unsafe operation happens.

Now, given that this function is actually unsafe in terms of its realtime consequences (it does not do any validation of the input for speed) I want to mark it as unsafe fn and make a safer wrapper for end users, while keeping this for the little subset of users that will need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any other unsafe operation in the body of the function, when what I wanted is just to force users of it to be aware of unsafety via compiler validation.

A safe {} block could have helped me in this case. But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one is unsafe but validated by programmer

I had this idea for some time and I'd like to discuss it to see if it is something reasonable to be proposed for rust to implement or there are other ways around the problem.

Let's say I have a low level function that manipulates the hardware clock using some platform-specific argument. Internally this function will do an unsafe volatile mem write to store value in the register, but this is the only part of the code that is unsafe compiler-wise, whatever else is in there in the function is safe and I want the compiler to warn me if any other unsafe operation happens.

Now, given that this function is actually unsafe in terms of its realtime consequences (it does not do any validation of the input for speed) I want to mark it as unsafe fn and make a safer wrapper for end users, while keeping this for the little subset of users that will need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any other unsafe operation in the body of the function, when what I wanted is just to force users of it to be aware of unsafety via compiler validation.

A safe {} block could have helped me in this case. But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one is unsafe but validated by programmer

It possibly makes sense to have a distinction between "functions
that are unsafe to call" and "functions that can call unsafe
functions internally", i.e. have `unsafe fn foo() { ... }` *not*
be the same as `unsafe fn foo() { unsafe { ... } }`, although I
imagine that this may make certain cases rather uglier.

Huon

On 01/01/15 22:46, Manish Goregaokar wrote:

It should be reasonably easy to write a lint as a
compiler plugin such that the following function:

#[unsafe_specific]

unsafe fn foo () {

#[allowed_unsafe] { // or just
#[allow(unsafe_something_something)]

// do unsafe things here

}

// no unsafe blocks or functions allowed here.

}

would not compile with any unsafe code in the latter half
of the function.

I had this idea for some time and I'd like to discuss
it to see if it is something reasonable to be proposed
for rust to implement or there are other ways around the
problem.

Let's say I have a low level function that
manipulates the hardware clock using some
platform-specific argument. Internally this function
will do an unsafe volatile mem write to store value in
the register, but this is the only part of the code that
is unsafe compiler-wise, whatever else is in there in
the function is safe and I want the compiler to warn me
if any other unsafe operation happens.

Now, given that this function is actually unsafe in
terms of its realtime consequences (it does not do any
validation of the input for speed) I want to mark it as
unsafe fn and make a safer wrapper for end users, while
keeping this for the little subset of users that will
need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any
other unsafe operation in the body of the function, when
what I wanted is just to force users of it to be aware
of unsafety via compiler validation.

A safe {} block could have helped me in this case.
But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one
is unsafe but validated by programmer

Re: Declaring the API unsafe while keeping the internal safety checks

> I had this idea for some time and I'd like to discuss it to see if it is
> something reasonable to be proposed for rust to implement or there are
> other ways around the problem.
>
> Let's say I have a low level function that manipulates the hardware
> clock using some platform-specific argument. Internally this function
> will do an unsafe volatile mem write to store value in the register, but
> this is the only part of the code that is unsafe compiler-wise, whatever
> else is in there in the function is safe and I want the compiler to warn
> me if any other unsafe operation happens.
>
> Now, given that this function is actually unsafe in terms of its
> realtime consequences (it does not do any validation of the input for
> speed) I want to mark it as unsafe fn and make a safer wrapper for end
> users, while keeping this for the little subset of users that will need
> the actual speed benefits.
>
> Unfortunately, marking it unsafe will now allow any other unsafe
> operation in the body of the function, when what I wanted is just to
> force users of it to be aware of unsafety via compiler validation.

Re: Declaring the API unsafe while keeping the internal safety checks

> I had this idea for some time and I'd like to discuss it to see if it is
> something reasonable to be proposed for rust to implement or there are
> other ways around the problem.
>
> Let's say I have a low level function that manipulates the hardware
> clock using some platform-specific argument. Internally this function
> will do an unsafe volatile mem write to store value in the register, but
> this is the only part of the code that is unsafe compiler-wise, whatever
> else is in there in the function is safe and I want the compiler to warn
> me if any other unsafe operation happens.
>
> Now, given that this function is actually unsafe in terms of its
> realtime consequences (it does not do any validation of the input for
> speed) I want to mark it as unsafe fn and make a safer wrapper for end
> users, while keeping this for the little subset of users that will need
> the actual speed benefits.
>
> Unfortunately, marking it unsafe will now allow any other unsafe
> operation in the body of the function, when what I wanted is just to
> force users of it to be aware of unsafety via compiler validation.

Re: Declaring the API unsafe while keeping the internal safety checks

Yes unsafe is primarily for memory safety. However! Your idea is good. It would be really good if you could have something like that. I am just not sure what the best way to do it is. It could be done by an attribute and lint with the ability to toggle it off with a module level, function level, or scope level second attribute, lol, possibilities are endless.

But indeed unsafe is likely only, currently, for memory safety.

Still I like the idea! I love the idea. I read your email earlier today but only shortly ago I realize what you mean.

I had this idea for some time and I'd like to discuss it to see if it is something reasonable to be proposed for rust to implement or there are other ways around the problem.

Let's say I have a low level function that manipulates the hardware clock using some platform-specific argument. Internally this function will do an unsafe volatile mem write to store value in the register, but this is the only part of the code that is unsafe compiler-wise, whatever else is in there in the function is safe and I want the compiler to warn me if any other unsafe operation happens.

Now, given that this function is actually unsafe in terms of its realtime consequences (it does not do any validation of the input for speed) I want to mark it as unsafe fn and make a safer wrapper for end users, while keeping this for the little subset of users that will need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any other unsafe operation in the body of the function, when what I wanted is just to force users of it to be aware of unsafety via compiler validation.

A safe {} block could have helped me in this case. But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one is unsafe but validated by programmer

Re: Declaring the API unsafe while keeping the internal safety checks

Well, strictly speaking it *is* memory safety, as it all gets down to an unsafe volatile store. Although I think I extend the 'unsafety' a bit by considering code that can cause CPU to halt as unsafe too.

Yes unsafe is primarily for memory safety. However! Your idea is good. It would be really good if you could have something like that. I am just not sure what the best way to do it is. It could be done by an attribute and lint with the ability to toggle it off with a module level, function level, or scope level second attribute, lol, possibilities are endless.

But indeed unsafe is likely only, currently, for memory safety.

Still I like the idea! I love the idea. I read your email earlier today but only shortly ago I realize what you mean.

I had this idea for some time and I'd like to discuss it to see if it is something reasonable to be proposed for rust to implement or there are other ways around the problem.

Let's say I have a low level function that manipulates the hardware clock using some platform-specific argument. Internally this function will do an unsafe volatile mem write to store value in the register, but this is the only part of the code that is unsafe compiler-wise, whatever else is in there in the function is safe and I want the compiler to warn me if any other unsafe operation happens.

Now, given that this function is actually unsafe in terms of its realtime consequences (it does not do any validation of the input for speed) I want to mark it as unsafe fn and make a safer wrapper for end users, while keeping this for the little subset of users that will need the actual speed benefits.

Unfortunately, marking it unsafe will now allow any other unsafe operation in the body of the function, when what I wanted is just to force users of it to be aware of unsafety via compiler validation.

A safe {} block could have helped me in this case. But is it a good idea overall?

Some pseudo-code to illustrate

pub unsafe fn set_clock_mode(mode: uint32) {

// ...

// doing some required computations

// this code must be 'safe' for the compiler

unsafe {

// ...

// writing the value to mmaped register, this one is unsafe but validated by programmer