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.
On Fri, Jan 2, 2015 at 2:11 AM, Kevin McGuire <kmcg3...@gmail.com> wrote:
> 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.
> On Jan 1, 2015 5:17 AM, "Vladimir Pouzanov" <farcal...@gmail.com> wrote:
>
>> 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
>> }
>> }
>>
>> pub fn set_clock_mode_safe(mode: uint32) -> bool {
>> // ...
>> // validate input
>> unsafe {
>> // I want this call to require unsafe block
>> set_clock_mode(mode);
>> }
>> }
>>
>> --
>> Sincerely,
>> Vladimir "Farcaller" Pouzanov
>> http://farcaller.net/
>>
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
--
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
