Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C++ standard for the F-35 Fighter Jet [video]

youtube.com

Post reply on HN
Print view View original

421–430 of 451 posts

Re: The C++ standard for the F-35 Fighter Jet [video]

#421

Post by p_l »

jll29 wrote: post #381
adolph wrote: post #371

Earlier quoted context omitted.

Since when was expense a problem for defense spending? In the video, the narrator also claims that Ada compilers were expensive and thus students were dissuaded from trying it out. However, in researching this comment I founds that the Gnat project has been around since the early 90s. Maybe it wasn't complete enough until much later and maybe potential students of the time weren't using GNU? The GNAT project started…

The DOD could easily have organized Ada hackathons with a lot of prize money to "make Ada cool" if they had chosen to in order to get the language out of the limelight. They could also have funded developing a free, open source toolchain.

GNAT exists because DoD funded a free, open source toolchain.

Re: The C++ standard for the F-35 Fighter Jet [video]

#422

Post by gghffguhvc »

psunavy03 wrote: post #379
gghffguhvc wrote: post #266

Earlier quoted context omitted.

The pilots might have reassessed after Pakistan seemed to have shot three of them down from over 200km range. Intel failure blamed but likely many factors of which some presumably may be attributed to the planes.

Pakistan has never downed an F-35.

I poorly worded it. Rafales allegedly shot down. After that happened, perhaps the pilots wanting them over F35s might have a different opinion. F35s might be harder to get a lock on at that distance and might have better situational awareness capabilities.

Re: The C++ standard for the F-35 Fighter Jet [video]

#423

Post by quietbritishjim »

0xffff2 wrote: post #400
adrian_b wrote: post #339

Earlier quoted context omitted.

You have to use the stack for procedure calls on x86/x86-64 CPUs, where the hardware enforces this. In most other surviving CPU ISAs the return address is saved in a register and it is easy to arrange in a compiler to use only procedure arguments that are passed in registers, the only price being paid for this being a reasonable upper limit for the number of parameters of a function, e.g. 12 or 24, depending on the n…

I honestly can't tell if you know a lot more than me or a lot less than me about how computers work... A couple of honest questions: 1. Where do you save the current value of the return address register before calling a function? 2. When parameters are "grouped into a structure" and the structure is passed as an argument to a function, where do you store that structure?

The sibling comment already answered your question, but just to add: As I mentioned earlier, this was actually how old programming languages worked. Famously(ish), Dijkstra secretly snuck recursive functions into the ALGOL 60 standard, thus forcing compiler authors to use a stack!

https://news.ycombinator.com/item?id=10131664

Re: The C++ standard for the F-35 Fighter Jet [video]

#424

Post by accelbred »

steveklabnik wrote: post #399
accelbred wrote: post #392

Earlier quoted context omitted.

No they could not. Rusts standard library heavily uses dynamic memory allocation and panics, for example. MISRA C:2025 Addendum 6 covers MISRA rules that still apply to Rust, as an example of how one would restrict Rust in safety-critical contexts.

In safety critical contexts, you're not usually using the standard library. Or at least, you're using core, not alloc or std. Panics can still exist, of course, but depending on the system design you probably don't want them either, which is a bit more difficult to remove but not the end of the world. I hadn't seen that addendum though yet, that's very cool!

Yeah, for work stuff where we follow MISRA conventions, its easiest to use no_std and ban using third-party crates as runtime dependencies.

Re: The C++ standard for the F-35 Fighter Jet [video]

#425

Post by accelbred »

mainecoder wrote: post #362

Did they really have to tell their programmers this ? (see Page 52) AV Rule 174 (MISRA Rule 107) The null pointer shall not be de-referenced.

The rule isnt there to say "don't do this". It's there to say "you must prove that this holds true, in any circumstance".

Re: The C++ standard for the F-35 Fighter Jet [video]

#426

Post by AnimalMuppet »

jandrewrogers wrote: post #387
mainecoder wrote: post #362

Did they really have to tell their programmers this ? (see Page 52) AV Rule 174 (MISRA Rule 107) The null pointer shall not be de-referenced.

There are old idioms in C where null pointers are intentionally dereferenced to induce the expected outcome. Not the best way to write that code because beyond being less explicit about intent it also isn't guaranteed to work. The rule is likely speaking to this code.

I've done it, I think more than once.

I was getting to a point in the code. I could tell by a log statement or some such. But I didn't know in what circumstances I was getting there - what path through the code. So I put in something like

  char *p = 0;
  *p = 1;
in order to cause a core dump. That core dump gave me the stack trace, which let me see how I got there.

But I never checked that in. If I did, I would expect a severe verbal beating at the code review. Even more, it never made it into release.

Re: The C++ standard for the F-35 Fighter Jet [video]

#428

Post by anonymousiam »

0xffff2 wrote: post #401
anonymousiam wrote: post #81

The same is true for the software that runs many satellites. Use of the STL is prohibited. The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can contin…

For what it's worth, I am an active developer of space flight software. This might be true somewhere, but it's not true anywhere I've ever encountered. The contortions required to avoid using the stack would be insane and cause far more bugs than it could ever prevent. I'm pretty confident asserting that this is simply not a thing. Even heap allocation is very often allowed, but restricted to program initialization o…

I'm guessing that you work for SpaceX.

Re: The C++ standard for the F-35 Fighter Jet [video]

#429

Post by lallysingh »

nmz wrote: post #385
lallysingh wrote: post #304

Earlier quoted context omitted.

No they won't. DoD is small compared to the rest of the software market. You get better quality and lower cost with COTS than with custom solutions, unless you spend a crap ton . The labor market for software's no different. Everyone likes to crap on C++ because it's (a) popular and (b) tries to make everyone happy with a ton of different paradigms built-in. But you can program nearly any system with it more scalably…

Go was built because C++ does not scale. Anybody that's ever used a source based distro knows that if you're installing/building a large C++ codebase, better forget your PC for the day because you will not be using it. Rust also applies here, but at least multiplatform support is easier, so I don't fault it for slow build times

Go was made because Rob Pike didn't want to do Java.

Re: The C++ standard for the F-35 Fighter Jet [video]

#430

Post by mrgaro »

superxpro12 wrote: post #357
mrgaro wrote: post #250

Earlier quoted context omitted.

I remember having this argument with my professor at the school, who insisted that a function should have only one "return" clause at the very end. Even as I tried, I could not get him to explain why this would be valuable and how does this produce better code, so I'm interested on hearing your take on this?

It helps prevent bugs with state. The apple login bypass bug comes to mind. Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt. Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state. In practice, at my shop, we permit early returns for trivial thi…

Thank you!
Post reply on HN