3 ms·

> Eventually I learned I had to rely on the standard instead of folklore Isn’t this the opposite of what should have been done in the case of coding systems fo

by _gabe_ 3y ago

> Eventually I learned I had to rely on the standard instead of folklore Isn’t this the opposite of what should have been done in the case of coding systems for a nuclear facility? I thought the whole point of the exercises was to show that C has lots of undefined behavior, so you should only rely on the behavior of the specific system you’re coding for. If the C standard doesn’t specify what happens when a signed integer overflows, that doesn’t mean you can just ignore it. You could crash the system, report an error, or find out what the targeted system is specified to do in the case of a signed integer overflow. Is there something else I’m missing here, or do the nuclear systems typically have several processors that may have varying behavior for this type of stuff?

dannymi 3y ago
>I thought the whole point of the exercises was to show that C has lots of undefined behavior, so you should only rely on the behavior of the specific system you’re coding for. In my opinion, the whole point of the exercise was to show that as an engineer, you should have an engineering mindset. And that means collecting requirements, selecting parts, reading a lot of specifications, and participate in writing them. C is an abstraction. If you program in C, you use that abstraction (so you use the standardized C abstract machine). Why would you program in C and NOT use that abstraction? If you want the latter, just use assembly. Especially in this application. Otherwise, yes, you hold yourself to the C standard, and you use compilers that are certified to actually implement that standard. Of course, there needs to be a lot (>50% of the total time) of testing, too. But not to figure out what the compiler does :P > If the C standard doesn’t specify what happens when a signed integer overflows, that doesn’t mean you can just ignore it. It means you have to write your programs in a way that signed overflow cannot happen. > You could crash the system, report an error, or find out what the targeted system is specified to do in the case of a signed integer overflow. Just make it fail (looong) before the signed integer overflow would happen (with proof). >what the targeted system is specified to do in the case of a signed integer overflow What does this mean? What is the "system" in this case? If the "system" is the hardware, then no. In standardized C, this overflow never makes it down to the hardware. If it's the hardware and the compiler, then sure, but you aren't programming standard C then. I guess you could do that (why would you, though... compliance is gonna reject it). > Is there something else I’m missing here, or do the nuclear systems typically have several processors that may have varying behavior for this type of stuff? In practice, you have certified compilers that are certified to actually implement the c standard correctly. >Is there something else I’m missing here, or do the nuclear systems typically have several processors that may have varying behavior for this type of stuff? You usually want to be independent of the processor (and/or vendor) used, in order to be able to easily switch it out in case they get uppity/lazy. That's one of the main uses of C.

by _gabe_ 3y ago

dannymi 3y ago

>I thought the whole point of the exercises was to show that C has lots of undefined behavior, so you should only rely on the behavior of the specific system you’re coding for. In my opinion, the whole point of the exercise was to show that as an engineer, you should have an engineering mindset. And that means collecting requirements, selecting parts, reading a lot of specifications, and participate in writing them. C is an abstraction. If you program in C, you use that abstraction (so you use the standardized C abstract machine). Why would you program in C and NOT use that abstraction? If you want the latter, just use assembly. Especially in this application. Otherwise, yes, you hold yourself to the C standard, and you use compilers that are certified to actually implement that standard. Of course, there needs to be a lot (>50% of the total time) of testing, too. But not to figure out what the compiler does :P > If the C standard doesn’t specify what happens when a signed integer overflows, that doesn’t mean you can just ignore it. It means you have to write your programs in a way that signed overflow cannot happen. > You could crash the system, report an error, or find out what the targeted system is specified to do in the case of a signed integer overflow. Just make it fail (looong) before the signed integer overflow would happen (with proof). >what the targeted system is specified to do in the case of a signed integer overflow What does this mean? What is the "system" in this case? If the "system" is the hardware, then no. In standardized C, this overflow never makes it down to the hardware. If it's the hardware and the compiler, then sure, but you aren't programming standard C then. I guess you could do that (why would you, though... compliance is gonna reject it). > Is there something else I’m missing here, or do the nuclear systems typically have several processors that may have varying behavior for this type of stuff? In practice, you have certified compilers that are certified to actually implement the c standard correctly. >Is there something else I’m missing here, or do the nuclear systems typically have several processors that may have varying behavior for this type of stuff? You usually want to be independent of the processor (and/or vendor) used, in order to be able to easily switch it out in case they get uppity/lazy. That's one of the main uses of C.