![]() For legacy safety-critical computer systems, software safety requirements may not have been formally specified during development. ![]() Safety-critical computer systems must be engineered to meet system and software safety requirements. Maybe it's just me, but it seems like the considerate thing to do, too.Software Safety Risk in Legacy Safety-Critical Computer Systems ![]() Making a copy of the argument passed to the client before mutating it would have saved everyone some trouble. The headers dictionary, as seen from the perspective of the HTTP client, originates from code that uses the client's API - a classic example of untrusted code. It also prevents changes to mutable objects passed into your code from untrusted sources. But in this case, and many others, the improvement in reliability justifies the tradeoff.ĭefensive copying doesn't just protect objects passed from your code into untrusted code. That protection comes at a price: increased memory overhead. The client still mutates the copy, but the original object is protected. Now you can safely pass a new copy of headers to the next request. The contents of headers are unchanged because a copy of headers - an entirely distinct object made with Python's deepcopy() function - was sent to the client instead. > # A copy of `headers` is sent to the client Here's the same problem faced by the SDK team expressed in Python: > headers = Can't be verified to comply with your expectations or is too costly to modify so that it does, as is often the case with legacy code.Displays bad behavior, such as the HTTP client, or.At a minimum, I think of untrusted code as any code that either: But that assumption isn't always practical in the day-to-day business of writing code. The pessimist in me believes that all code is untrustworthy. Let me clarify what I mean by untrusted code. It's exactly how the SDK team handled the issue with the HTTP client:ĭefensive copying: Making a copy of mutable objects before sending them to, or after receiving them from, untrusted code. Not two weeks prior, I read the section on defensive copying. The book looks at how functional programming is used in practice, largely avoiding the theory by focusing on how functional concepts can improve real-world systems. I've been reading Grokking Simplicity by Eric Normand. The incident with the HTTP client was timely for me, in a way. Without a doubt, though, one situation where immutability helps is dealing with untrusted code. Whether or not you should strictly maintain immutability in your code is a question you'll have to answer for yourself or with your team. NASA's The Power Of Ten: Rules For Developing Safety Critical Code by Gerald Holzmann gives a rationale for defensive programming. The Sins of Perl Revisited by Mark-Jason Dominus, discusses the origin of the term "action at a distance." The Reading on Thread Safety from MIT's Software Construction course has a decent overview of immutability, thread safety, and concurrency. Learn More Here are some resources on the benefits of immutability: Programming Safety Tips: Why You Should Use Immutable Objects by Charles Kann shows how an elusive memory error is easily fixed with immutability.
0 Comments
Leave a Reply. |