Imported document about undefined behavior and safe api in LLD

[pellico]

No description provided.

[PLeVasseur]

Hi @pellico -- I gave this an initial read today, found a few suggestions. I'd like to read through it again and review.

I'd suggest posting a link to this PR into the Zulip to see if we can have further review by others as well 🙂

[vapdrs]

Interesting read. I left some comments, mostly grammar related.

[PLeVasseur]

@pellico -- I know this has been here for a bit. I'm hoping that you coordinating with the Embedded WG to discuss the concept further (perhaps having some sort of cross-over meeting / discussion in a small group?) and the work @adfernandes will work on for the "what is unsafety" pamphlet can better flesh out where to draw the line.

As I've mentioned, it's possible for us in the safety-critical space to draw the line in that gray zone a bit closer to the side of "safety".

[pellico]

@pellico -- I know this has been here for a bit. I'm hoping that you coordinating with the Embedded WG to discuss the concept further (perhaps having some sort of cross-over meeting / discussion in a small group?) and the work @adfernandes will work on for the "what is unsafety" pamphlet can better flesh out where to draw the line.

As I've mentioned, it's possible for us in the safety-critical space to draw the line in that gray zone a bit closer to the side of "safety".

I am perfectly fine with this solution. However what I described is applicable also to external libraries. I don't see any difference between calling an external function or start an operation of external peripheral.
So I would like to see how the definition of undefined behavior will evolve in the context of external libraries and then see the definition is applicable to embedded system as well.

[vapdrs]

Looks good to me

[PLeVasseur]

Hey @pellico -- main thing I'd like to emphasize is that this may or may not be a Rust Project concern, it may be a svd2rust crate or Tools team concern or even simply within the domain of safety-critical if they don't feel it's within their realm of responsibility. I'd like to have this portion rewritten if possible.

I've given some minor edit suggestions here and there otherwise.

[PLeVasseur]

Suggested change

	Before discussing safe/unsafe in Low Level Drivers let`s see the meaning
	Before discussing safe/unsafe in Low Level Drivers let's see the meaning

[PLeVasseur]

I'll highlight this one here as I think my ask wasn't clear. It seems you're using tilde (`) instead of apostrophe (') in spots in the document. I was trying to note those spots. Could you switch the tildes for apostrophes where needed?

[PLeVasseur]

From my point of view, we should be careful to delineate those things which the Rust Project and most of the Rust community would say lead to "undefined behavior" from a particular (and important!) segment which cares about safety-critical and writing low-level drivers.

I think that this involves some advocacy on our part as the Safety-Critical Rust Consortium Coding Guidelines Subcommittee.

As we have chatted about a few times, this seems to be a bit of a "scoping" or "system" issue where as you show here it depends on how you view the scope of your system and how it can do things which lead to "undefined behavior".

I'd recommend rewriting this section here to emphasize perhaps this "community" nature, since as you highlight the svd2rust crate here (which is maintained by the Tools team) is a first major collaborator in this mission you're embarking on.

[pellico]

@PLeVasseur This was an old document that I though could be useful as food for thought and I have no problem to change.

The main point that I tried to highlight is that there is an inconsistency in the community regarding the definition of undefined behaviors and when use or not use unsafe keyword.

This inconsistency in the scope of safety this inconsistency can lead to different interpretation and therefore safety risk.

I would propose to rewrite the document in following way:

• Highlight the inconsistency/unclarity of unsafe usage and undefined behavior definition across Rust community
• Remove any reference to svd2rust
• Remove all reference to HW peripheral (I will mention only interface to C Low Level Driver) and consider a more generic external world (FFI)
• Remove the section about solution proposal and call for a community solution, better definition in Rust upcoming specification or just a guidance in coding guidelines.
• Highlight the risk of this ambiguity in the context of safety application.

Is this addressing your recommendation ?

[PLeVasseur]

I think you've got the start of a useful document here to drive discussion, for sure.

The aspect that I think you address pretty well and could be due more emphasis is what we often look at in a safety-critical context, which is of system scoping, i.e. where the safety issues could crop up.

While in a vacuum calling a certain API that's FFI or directly accessing memory or manipulating hardware may not cause a safety concern from the point of view, it's within the greater context of what a system is trying to accomplish that something may result in undefined behavior. Your diagrams and explanations I think go to that point.

The main point that I tried to highlight is that there is an inconsistency in the community regarding the definition of undefined behaviors and when use or not use unsafe keyword.

My main challenge with the document as-is is in this framing. I think that within the context of the Rust programming language the understanding of undefined behavior is ~reasonably well-defined.

However, when we take a function call that's doing something which in and of itself doesn't cause undefined behavior, but due to the ordering of the function called with respect to another function, that's where this system scoping framing can be useful.

e.g.

• Calling a foo() function: defined
• Calling foo(), then bar() functions: defined
• Calling bar(), then foo() functions: undefined behavior

Therefore, when doing a low-level driver that should accomplish foo() + bar() we will consider the system scope as surrounding both of them to ensure they're called in the correct order.

I think it's admirable to say that low-level software that's still fairly close to manipulating hardware should not be unsafe! I'd like to make sure it's being motivated and communicated in this way.