19 ms·

NASA has a list of 10 rules for software development

• jmclnx 2y ago
  nice, saved because these days who know ho long the page will be available :)
• readthenotes1 2y ago
  Someone in NASA once told me that it was easier to teach a mechanical engineer to program then a software developer mechanical engineering. From that perspective, the avoidance of recursion is more compelling. Plus, Fortran didn't support it...
  • paulluuk 2y ago
    I'm curious, how does that perspective make the avoidance of recursion more compelling?
    • airbreather 2y ago
      Recursion can be good, predicting you will never run out of stack or not, can be hard. It's a little hard to duck out to Mars to reboot the lander after you bricked it with a recursive function that never exited.
    • readthenotes1 2y ago
      Recursion was a filter topic when I went through computer science training. Some people couldn't get it.
  • grandempire 2y ago
    This is a common attitude in other engineering fields, but they also don't tend to have outstanding software and don't care to.
• dooglius 2y ago
  Title should indicate that this is a _criticism_ of the rules.
  • killingtime74 2y ago
    It's more like a commentary
  • Enginerrrd 2y ago
    Yeah and also one that I'm not very impressed with. The criticism is (mostly) super contrived and totally misses the wisdom behind why some of these rules were made in the first place. A lot of the author's points are very reminiscent of the same classic rebuttal against criticisms of the C language for being insecure: "It's perfectly fine if you're good and don't make stupid mistakes." That's just not a very mature view of working with groups of human beings. Most of these rules are designed to reduce errors that are difficult for humans to see by making the code more readable, deterministic, and avoiding situations that can lead to unintended behavior that is subtle in its true complexity. Creating a series of "Gotchas" where it perhaps negates that idea in an obscure situation doesn't really mean that the rules don't tend to produce code that is more reliable and auditable. Some of these rules really do seem kind of anachronistic, but... then again there's still a lot of old FORTRAN code and the like running on NASA hardware.
    • wduquette 2y ago
      Most of these rules are designed to make it possible to debug errors from millions of miles away, with extremely limited visibility into the program’s state, so that failure modes can be predicted, understood, and resolved on the ground, and worked around as needed, so that we don’t lose a spacecraft in deep space.
• einpoklum 2y ago
  Well, I was expecting to see: Rule 1: Don't write any code that can make the ship go ka-boom. Rule 2: We need to consistently use the f'ing metric system and SI units - and don't you forget it. Rule 3: ... You haven't already forgotten about rule #2, have you?
  • shwoopdiwoop 2y ago
    What’s wrong with using the metric system?
    • Swizec 2y ago
      Is a reference to this famous incident of a mars lander slamming into mars due to mismatched units. https://everydayastronaut.com/mars-climate-orbiter/ https://everydayastronaut.com/mars-climate-orbiter/
      • kanbankaren 2y ago
        Not sure whether they used a value pattern. typedef struct { float value; } meter; typedef struct { float value; } feet; Using strong typing, you can avoid passing values in wrong units.
        • einpoklum 2y ago
          In C++, there are a few very nice libraries for computation with units, e.g.: https://github.com/mpusz/mp-units https://github.com/mpusz/mp-units which does all sorts of checking, allows arithmetic with proper accounting for units and so on. But yes, the basic notion is wrapping things in structs which can't be simply assigned to each other.
        • dgoodell 2y ago
          The mars probe unit problem was mismatched between different software programs. One was telemetry reported by the spacecraft to the ground, the other was software on the ground that used this telemetry to perform calculations that reported the results with the incorrect units. Maybe the answer is that strong typing should somehow continue outside of the individual programs and be embedded in file formats as well?
• nealabq 2y ago
  No recursion means no Erlang. Which means no RabbitMQ?
  • AlotOfReading 2y ago
    Erlang seems like a strange choice for deeply embedded hard realtime systems that aren't supposed to ever crash. It's a different set of tradeoffs than Erlang makes.
    • PaulRobinson 2y ago
      Erlang was designed for running telephone exchanges - about as deeply embedded hard realtime a system as you can get, that needs to be fault tolerant otherwise 911 goes down.
      • AlotOfReading 2y ago
        Erlang is typically used for soft realtime systems on fairly powerful non-embedded hardware. There have been attempts to use it in hard realtime systems, but no successful ones that I'm aware of.
  • ajross 2y ago
    You say this as if it's somehow an obvious thing that... we clearly need RabbitMQ on spacecraft?
  • moffkalast 2y ago
    Thankfully, yes. Spacecraft use outdated hardware with heavy limitations where a stack overflow is a genuine possibility. You're not even supposed to use a heap in general, static vars all the way. It's like writing stuff for a shitty microcontroller where you run out of RAM if you take one wrong turn.
• toolslive 2y ago
  from the original document: "critical code is written in C." The document is not dated, but it's probably quite old (I'm guessing 30-something years). Writing critical code in C is probably a mistake, but once you find yourself in that situation, you will find these rules are too tight (which is also what the criticism is about). You should probably read them as "try to avoid ...". So I would just prepend the document with "Rule 0: Try to avoid writing critical code in C."
  • airbreather 2y ago
    Sometimes, eg aspects of automotive functional safety, MISRA C might be all you get. These NASA principles are more about enabling better possible static analysis of the code and ease of someone else, maybe decades later, debugging or pushing changes to something likely on another planet. Also you have to remember space based computing lags well behind terrestrial computing because of the radiation hardening. They are often still dealing with legacy systems that might be 8 bit with very limited memory, they were still in the hardware expensive engineers cheap mode until well into the nineties, if not later. Rad750s run at 400 mips and were, and maybe are, preferred choice of processor.
    • toolslive 2y ago
      These days, there are compilers for embedded systems that can prove for certain code (for example) that it runs in constant time and constant space. As an example, galois.com has been doing this for Haskell, not just for embedded systems, but also for even more low level things like FPGAs.
• deleted 2y ago
  [deleted]
• zoogeny 2y ago
  > People using Ada, Pascal (Delphi), JavaScript, or functional languages should also declare types and functions as locally as possible. My own personal approach in JavaScript is to avoid defining functions in a nested manner unless I explicitly want to capture a value from the enclosing scope. This is probably due to an outdated mental model I had where it was shown in performance profiling that a function would be redefined every time the enclosing function was called. I doubt this is how any reasonable modern JavaScript interpreter works although I haven't kept up. Since the introduction of arrow functions (a long time ago now in relative terms) their prolific use has probably lead to deep optimizations that render this old mental model completely useless. But old habits dies hard I guess and now I keep any named function that does not capture local variables at a file/module scope. A lot of the other notes are interesting and very nit-picky in the "technically correct is the best kind of correct" way that older engineers eat up. I feel the general tone of carefulness that the NASA rules is trying to communicate to be very good and I would support most of them in the context that they are enforced.
  • Gibbon1 2y ago
    I use gcc's nested functions a fair amount. Because it reduces cutting pasting and makes the code much easier to understand. I use variable argument macro's to implement debug print functions for debugging. And I just leave them in the code as a form of documentation. Looking at the debug print statements tells you a lot of about what the code is doing.
    • shakna 2y ago
      Unfortunately, as useful as they really are, GCC's nested functions are usually done via trampolines, which means an executable stack. That's not really a safe thing, when dealing with critical systems, like NASA regularly do.
      • LiamPowell 2y ago
        This isn't the case for Ada on GCC, so the support is there, it just hasn't been extended to C: > The use of trampolines requires an executable stack, which is a security risk. To avoid this problem, GCC also supports another strategy: using descriptors for nested functions. Under this model, taking the address of a nested function results in a pointer to a non-executable function descriptor object. Initializing the static chain from the descriptor is handled at indirect call sites. > On some targets, including HPPA and IA-64, function descriptors may be mandated by the ABI or be otherwise handled in a target-specific way by the back end in its code generation strategy for indirect calls. GCC also provides its own generic descriptor implementation to support the -fno-trampolines option. In this case runtime detection of function descriptors at indirect call sites relies on descriptor pointers being tagged with a bit that is never set in bare function addresses. Since GCC’s generic function descriptors are not ABI-compliant, this option is typically used only on a per-language basis (notably by Ada) or when it can otherwise be applied to the whole program. > For languages other than Ada, the -ftrampolines and -fno-trampolines options currently have no effect, and trampolines are always generated on platforms that need them for nested functions. From: https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
• jsrcout 2y ago
  I work with a lot of embedded and embedded-adjacent software, and even I think several of these rules are too much. Having said that, Holzmann's rules are from 2006, and embedded / space qualified hardware has improved quite a bit since then. These days planetary probes run C++, and JWST even uses JavaScript to run command scripts. Things are changing.
• raylus 2y ago
  Note this is NASA/JPL, not NASA-wide, JPL is a NASA center (FFRDC).
  • moffkalast 2y ago
    "I'd just like to interject for a moment. What you're referring to as NASA, is in fact, NASA/JPL, or as I've recently taken to calling it, NASA plus JPL. JPL is not a government agency unto itself, but rather another free component of a fully functioning NASA agency made useful by the labs, production facilities.."
• matu3ba 2y ago
  Example 1 is a deficit of C with missing computed goto and switch continue. Example 2 review is ambiguous on practicality. Example 3 reads very odd, an over-approximated upper stack bound is very possible https://github.com/ziglang/zig/issues/157#issuecomment-763952294 https://github.com/ziglang/zig/issues/157#issuecomment-76395... and tighter computation with advanced analysis as well. Example 4,5,6,7,8,9,10 yes. Overall good read.
• layer8 2y ago
  The rule about recursion is likely also to ensure a statically known bound on needed stack space, in addition to a statically known runtime bound (in conjunction with the other rules). While the criticism of rule 3 is right in that there is a dependence on the compiler, it is still a prerequisite for deriving upper bounds for the runtime by static analysis on the binary. This is actually something that is done for safety-critical systems that require a guaranteed response time, based on the known timing characteristics of the targeted microprocessor.
  • ajross 2y ago
    > The rule about recursion is likely also to ensure a statically known bound on needed stack space It's definitely that. Static stack size analysis in the embedded world is a long-standing paradigm and recursion and function pointer indirection defeat that. If the point of rule was that NASA was arguing that recursive constructions are always harder to reason about than iterative ones, then obviously NASA is wrong.
    • AnimalMuppet 2y ago
      If hard realtime and stack space are part of your constraints, then recursive constructions are in fact always harder to reason about.
      • ajross 2y ago
        To clarify: it's not stack "space" that's at issue. It's the requirement that the lack of stack overflow at runtime be formally verified. If functions exist in a static call tree[1] you can do this with a little disassembly wizardry and a few hundred lines of python. If you allow them to call themselves recursively, or even to indirect through a function pointer, it becomes undecidable. [1] There are some other related rules like "no alloca()".
        • rcxdude 2y ago
          Function pointers are possible to deal with, with varying levels of automation. You can detect when pointers to functions are taken, and tie them to call sides with type information or some manual work (I have a static analysis tool which allows function pointers for callbacks by linking functions passed into one function to the list of possible destinations for a given callsite). Recursion is harder but it's still possible in principle to prove a bound in a lot of cases, given a proof framework. Not something I'd encourage, though.
• AndyKelley 2y ago
  If I made my own criticism of these rules it would be very different from OP. It was difficult to take the article serious from the get-go when it defended setjmp/longjump. That pattern is so obviously broken from anyone who has ever had to go near it. The article makes an argument like this: 1. setjmp/longjmp is exception handling 2. exception handling is good and I take serious issue with that second premise. Also the loop thing obviously means to put a max iteration count on every loop like this: for (0..N) |_| { } where N is a statically determined max iteration count. The 10^90 thing is silly and irrelevant. I didn't read the article past this point. If I were to criticize those rules, I'd focus on these points: * function body length does not correlate to simplicity of understanding, or if anything it correlates in the opposite way the rules imply * 2 assertions is completely arbitrary, it should assert everything assertable, and sometimes there won't be 2 assertable things
  • bluGill 2y ago
    Exception handling in non trivial code is more performant than all the if else sequences to handle errors - if you even handle errors which odds are you won't. but it needs to be in the language so that the tricky code is write once.
    • throw-qqqqq 2y ago
      The part about “non trivial code” does a lot of lifting here. I would say your statement is untrue in general in at least a few languages. In .NET and Java it costs at least 100x as much time to throw an exceptions as to return an error code. Other languages may have cheaper exceptions, but for many mainstream languages, you pay a big performance price for exceptions. That price is often offset by other positive things, so the tradeoff is made willingly and with eyes open.
      • elygre 2y ago
        You pay the cost only when the exception is raised. If that happens on more than 1% of your runtime checks, it probably is not (aka should not be) an exception.
• dehrmann 2y ago
  Friendly reminder that you are most likely not NASA and have different goals, so you should approach the problem differently. The cost of a stack overflow (even at FAANG-scale) for you is likely many orders of magnitude cheaper than for NASA, and the cost of delaying a project for a year is much worse. Unless you work on commercial aircraft avionics. NASA flying a probe into Mars makes them look dumb. Flying an aircraft into a mountain haunts people for the rest of their lives.
• bumby 2y ago
  Just for context, these aren’t really “rules” as much as proposed practices. Note that official “rules” are in documents with names like “NPR” aka “NASA procedural requirements.”[1] So, while someone may use the document in the featured article to frame a discussion, a developer is not bound to comply (or alternatively waive) those “rules” and could conceivably just dismiss them. [1] e.g. https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2...
  • westurner 2y ago
    awesome-safety-critical lists a number of specs: https://awesome-safety-critical.readthedocs.io/en/latest/#software-safety-standards https://awesome-safety-critical.readthedocs.io/en/latest/#so...
    • bumby 2y ago
      Just be aware that some of the NASA-specific ones fall into a similar category. NASA “guidebooks” and “handbooks” aren’t generally hard requirements.
      • westurner 2y ago
        From "The state of Rust trying to catch up with Ada [video]" https://news.ycombinator.com/item?id=43007013 https://news.ycombinator.com/item?id=43007013 : >> The MISRA guidelines for Rust are expected to be released soon but at the earliest at Embedded World 2025. This guideline will not be a list of Do’s and Don’ts for Rust code but rather a comparison with the C guidelines and if/how they are applicable to Rust /? Misra rust guidelines: - This is a different MISRA C for Rust project: https://github.com/PolySync/misra-rust https://github.com/PolySync/misra-rust - "Bringing Rust to Safety-Critical Systems in Space" (2024) https://arxiv.org/abs/2405.18135v1 https://arxiv.org/abs/2405.18135v1 ... > minimum of two assertions per function. Which guidelines say "you must do runtime type and value checking" of every argument at the top of every function? The SEI CERT C Guidelines are far more comprehensive than the OT 10 rules TBH: "SEI CERT C Coding Standard" https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?contentId=87152044#content/view/87152044 https://wiki.sei.cmu.edu/confluence/plugins/servlet/mobile?c... "CWE CATEGORY: SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM)" https://cwe.mitre.org/data/definitions/1162.html https://cwe.mitre.org/data/definitions/1162.html
• manmal 2y ago
  > All loops must have a fixed upper-bound Things like spinlocks or CAS (Compare-And-Swap) are elegant and safe solutions for concurrency, and AFAIK you can’t really limit their upper bound. Others in the thread have pointed out that those are more guidelines than rules - still, not sure about this one.
  • TheBlight 2y ago
    I suspect multi-threaded programming for spacecraft is frowned upon at NASA.
    • RossBencina 2y ago
      Not sure about now, but it apparently was allowed when the Mars Pathfinder priority inversion problem happened.
      • TheBlight 2y ago
        AIUI that involved the scheduler for multiple processes not threads.
  • PaulDavisThe1st 2y ago
    Historically, the right limit for a loop around a spin lock/CAS was related to the effective time cost of a context switch (taking into account both the register save/restore and TLB flush). This is not a fixed number across all hardware but it is knowable upper bound.
    • manmal 2y ago
      That’s an interesting perspective. I‘m not sure I‘d ever be able to act on this outside of some embedded environments - even there, we now have actual OSs and the variance that comes with them.
      • PaulDavisThe1st 2y ago
• redtriumph 2y ago
  My ex-boss completed his PhD thesis with author of this doc as his advisor. So some of the ideas seem relevant since they popped up in few of the work related conversations with my boss.
• gorfian_robot 2y ago
  now raise your hand if you are actually in the business of writing code being deployed on JPL missions ..... bueller? bueller???
  • fallingmeat 2y ago
    Could apply to any application involving functional safety requirements
• wileydragonfly 2y ago
  The physical constraints of a sheet of paper are pleasing to the eye. Otherwise the dimensions of paper would be different. Oh well, it was good for a chuckle.
• jph 2y ago
  Read the original and it explains the purpose of each item: https://spinroot.com/gerard/pdf/P10.pdf https://spinroot.com/gerard/pdf/P10.pdf The original clearly describes that the coding rules primarily target C and attempt to optimize the ability to more thoroughly check the reliability of critical applications written in C. The original author clearly understands what they're doing, and explains lots of other ways to verify C code. For what it's worth, the rationales in the original all make perfect sense to me. Perhaps this is because I learned C on tiny systems? I learned C for hardware for implanted medical devices, and our lab did similar kinds of guidelines.
  • dgfitz 2y ago
    That pdf reads like the first draft of a guide on "how to write safety-critical code" and probably inspired things like DO-178, LOR1, DAL-A, 882, all sorts of standards. Writing C code for a safety-critical system running on an RTOS really humbled me. Felt like I should make more than I did relative to peers slinging code using 748mb of ram in a browser tab. ;D
    • revskill 2y ago
      Or replace all with zig.
      • pjmlp 2y ago
        Zig's safety is at the level of Object Pascal, Modula-2 and similar. Way better than plain old C, yet there are some weaknesses on the armour, and we know better since AT&T's Cyclone project.
      • otabdeveloper4 2y ago
        Yes, rewriting all the world's software in boutique untested languages is surely the way to write safe and reliable software. Because, you know, all the crusty idiots writing software before you didn't know about the wonders of syntactic sugar and automatically installed dependencies.
• fallingmeat 2y ago
  fun fact, the same guy (G Holzman) also made the Spin model checker
• lincpa 2y ago
  [dead]
• throwaway2037 2y ago
  The final paragraph is brilliant: > If the rules seem Draconian at first, bear in mind that they are meant to make it possible to check code where very literally your life may depend on its correctness: code that is used to control the airplane that you fly on, the nuclear power plant a few miles from where you live, or the spacecraft that carries astronauts into orbit. The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.
  • NetOpWibby 2y ago
    Yeah I think I’ll stick to building websites and web apps.
    • callc 2y ago
      You never know, your website may just be mission critical, like if there’s some code on the ISS running: while true; do wget $NetOpWibby_website || sudo shutdown; done
      • FpUser 2y ago
        Sure, they have to worry that some imbecile makes mission critical code depend on some dating website.
        • yellowapple 2y ago
          Someday scientists are going to want to study human reproduction in microgravity in order to test the feasibility of space colonization, and "some dating website" will indeed be something on which mission critical code depends.
          • cess11 2y ago
            Why would colonial powers let subjects control their own reproduction?
• rednafi 2y ago
  This makes me love Go even more. Gotta appreciate the things that the compiler takes care of for me. While I wish the stop-the-world GC pause were more predictable and took less time, I’ll gladly pay the cost for safety. Zig seems interesting, too. It feels like a better C, and I’m closely following its development as it marches toward 1.0.
  • glitchc 2y ago
    Stop-the-world GC pause can never work for a safety critical system (motor controller, elevator system). That pause could mean a crushed human appendage or worse.
    • rednafi 2y ago
      I don’t work in a safety critical system. If it works for Cockroach DB, it works for my use case. It’s a tradeoff I make to be able to use a nicer and safer language.
      • Narishma 2y ago
        They I don't see what you point was since these rules are specifically for safety critical systems written in C.
• emorning3 2y ago
  Looking over the list I determined that I already regularly follow all the rules but the first three. But, as a C#/C++/Typescript developer, I don't have the first clue how any I might go about implementing those rules. Anybody know of patterns for this kind of safe programming that I can use? Does just using a language like Zig automatically make my code 'safe'? Anybody know if generating code from a proof checking language like Lean would satisfy all these rules?
  • bluejekyll 2y ago
    Rust pretty much nails all of those.
    • nicce 2y ago
      Not really. By default allocators will panic if there isn't physical memory available. Recursive functions can cause panic at certain depth. Code generated by macros isn't very visible for the developers and recursive macros are very common. Return types are checked only if the developer adds #[must_use]. You can overcome lot if you invest a lot for type system, but that depends on the developer.
• kazinator 2y ago
  These rules are obviously for something critical. I don't think they are saying that if you write some kind of service program at NASA, it cannot have an infinite loop for taking requests. Or if you write a line-by-line file processing utility, it has to cap out at a maximum number of lines so that the loop is statically bounded. Or that if you write some tool to process syntax, perhaps a compiler, that you cannot use recursion. These are not embedded, safety-critical things.
  • bumby 2y ago
    NASA requires their software to be classified based on risk. The requirements that get levied are supposed to be commensurate with the risk. (Eg human-rated safety critical software has more stringent requirements that basic business software, although they write both)
• EVa5I7bHFq9mnYK 2y ago
  I'm terrified - do they really use C at NASA? I thought it's all ADA. In fact, most of the rules would be automatically satisfied by an early FORTRAN, as it had no heap, no stack and no recursion.
• ozim 2y ago
  Nothing special as those are like MISRA C rules from automotive industry. I see that is repackaging of low level rules and not some „magical 10 development rules” that would apply to your yet another CRUD app. Not to bash article just informing people who would write „software engineering is not real engineering” - it is real engineering and there are norms. Just because someone did not hear about standards and rules and practices doesn’t mean there are none.
  • scraptor 2y ago
    Of course the more forty year old rules you follow the more engineering it is. Using a better programming language that doesn't depend on organisational process for safety is not engineering - there's no standard for that.
    • ozim 2y ago
      How did you come up with such conclusion? Argument is only that there is a lot of proper engineering in software development - whether it is implementing memory safety by default in new languages or having organizational processes. All is there and I only dislike opinions that say software development is immature new field. It is not. Article was also about NASA organization rules so pointing to MISRA was argument „it is. It only NASA and those are not so special rules”.
• stevoski 2y ago
  Did I just go back 40 years in time?
  • rollcat 2y ago
    All of these guidelines are perfectly applicable for modern mission-critical or embedded code, which is a big chunk of what NASA does (sending stuff into space, including people, and keeping it operational / bringing them back), and been doing for far longer than 40 years. Even then, the essence (code clarity, robustness, tooling/static analysis, etc) is a good guideline for general code. You can play fast & loose with prototypes/MVPs, or one-off scripts, but once it's time to bring it to production and maintaining it long-term, you will be grateful to yourself for keeping stuff clean.
• jeffreygoesto 2y ago
  I don't like the "I criticize you for not having my use case" attitude.
• vasco 2y ago
  Safer to put 50 interns each working on their own version of the code and the have it run 50 times in parallel and choose the answer that most of them agree to. No need for standards then. Probably also more robust to radiation bit flips.
  • procaryote 2y ago
    This assumes the 50 interns have no systematic error. In practice, inexperienced developers tend to make similar mistakes
    • pasc1878 2y ago
      Especially if they are now using AI to check or write the code.
• IshKebab 2y ago
  Very C centric. > The assertion density of the code should average to a minimum of two assertions per function. I would actually say the opposite in modern languages like Rust. Assertions are a sign you have failed to encode requirements in the type system.
  • deleted 2y ago
    [deleted]
  • nicce 2y ago
    > I would actually say the opposite in modern languages like Rust. Assertions are a sign you have failed to encode requirements in the type system. Maybe. You still shouldn't write unsafe code without asserts.
• procaryote 2y ago
  > Note that setjmp() and longjmp() are how C does exception handling, so this rule bans any use of exception handling. In theory yeah, but I've very rarely encountered it in the wild. It's hard to use right in any code that has cleanup to do, without building a lot of infrastructure for resource handling.
• procaryote 2y ago
  This is written with a weird attitude of trying to find problems with the rules. Take this for example: > This does a bounded number of iterations. The bound is N^10. In this case, that's 10^90. If each iteration of the loop body takes 1 nsec, that's 10^81 seconds, or about 7.9×10^72 years. What is the practical difference between “will stop in 7,900,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years” and “will never stop”? ... yes, you're very smart and have found a way to technically satisfy the requirement while building a broken program Clearly the upper bound rule is to make it easy to reason about worst-cases so setting a very high one isn't really the gotcha they seem to think it is. It just means you can look at the high bound and go "this is too high, fix it"
• christophberger 2y ago
  The first rule of writing safety-critical systems in C: Don't write safety-critical systems in C.
• fullstackwife 2y ago
  They write the right stuff: - https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff (pdf: https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20Write%20the%20Right%20Stuff.pdf https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...)
• jmull 2y ago
  int const N = 1000000000; for (x0 = 0; x0 != N; x0++) for (x1 = 0; x1 != N; x1++) ... for (x9 = 0; x9 != N; x9++) -- do something --; Rule 1 would disallow this. Probably other rules as well, depending on the details for your code analysis tools. Also the article seems to imply the rule about recursion was about knowing your program would terminate, but the rationale from the rules says it's about verifying execution is bounded. That's a somewhat different concept. With recursive calls you have the stack to consider.
• ccosmin 2y ago
  No function pointers? That severely restricts the utility of the language…
  • deleted 2y ago
    [deleted]
• alkonaut 2y ago
  This looks more like rules for C development. In order to make reliable software in C (which is honestly pretty brave to begin with once you get past a certain complexity treshold).
• davemp 2y ago
  > Since programmers these days typically read their code on-screen, not on paper, it's not clear why the size of a sheet of paper is relevant any longer. Folks spent a while (centuries?) iterating on the standard page and character sizes. It makes sense to me that what we landed on wasn’t solely due to the limitations of paper, but also the limitations of humans.
• HarHarVeryFunny 2y ago
  It seems they also need. 11. Use strict typing for all scalar types. Do not mix imperial and metric units.
  • esafak 2y ago
    > Do not mix imperial and metric units. Value types to the rescue. I use them liberally.
• osigurdson 2y ago
  Rule 11: Use metric for everything
  • deadlydose 2y ago
    You can use anything you want as long as you are consistent and don't mix units.
    • osigurdson 2y ago
      https://ntrs.nasa.gov/citations/19930014020 https://ntrs.nasa.gov/citations/19930014020
• jcarrano 2y ago
  GCC, at least, allows you to get stack usage (after compilation), and caller-callee relationships (-fstack-usage, -fcallgraph-info, etc). From this one can infer maximum stack size. It will not work with recursion or function pointers, unless one manually incorporated additional data. setjmp() and longjmp(), are a poor way of handling exceptions, as any cleanup code won't be executed. Of course, following the spirit of these rules, one would not have resources that need cleaning up but still. The main issue, that is never mentioned, because it will be different in each application, is what to do when something goes wrong. Say an iteration limit is exceeded, or the fixed resources allocated at startup are not enough.
• rollcat 2y ago
  I think some of these recommendations, while overall excellent, are somewhat self-contradictory. For example, functions that are no longer than one screenful, AND ban on function pointers, AND the general rule to keep the codebase readable. How do you implement a state machine, like a byte code interpreter? You need some way to dispatch functions based on opcodes. You could argue it has no place in mission-critical code, but well-understood, time-bound state machines (like Plan9-style regexes or BPF) can actually greatly increase code readability. Also: Greenspun's tenth rule.
• jonesn11 2y ago
  Good thing to give to LLMs as well.