>I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.
Tell me what subset of the repo named "bc" you consider to be "the program"
>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.
Crates like tokio::signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans. Since the existing stack is not interrupted in any special way, dtors fire as they're supposed to.
tokio::signal-type code would not work for `bc` signals.
`bc` is a special program; most programs are I/O-bound, but `bc` is both I/O- and CPU-bound. And it's interactive, so it's got to respond to the user as fast as possible.
It's quite possible for a user to enter an expression, not realizing how expensive it is to compute (since `bc`'s numbers can be arbitrarily large). In that case, a `SIGINT` should be responded to instantly.
Turning signals into an event stream to read would not do that because the signal handler literally has to `longjmp()` out of itself.
It won't `longjmp()` out if it's not safe to do so, but it can be safe to do so. And when it is not safe to do so, it will set a flag and return normally.
Then the code that wasn't safe to jump around finishes, it will check the flag and jump itself once it is safe.
This is what keeps my `bc` responsive even if you have a long-running computation.
To see this, compile and run my `bc`, and give it this input:
>>> 2^2^32
It will hang because it's calculating a LARGE number.
Press Ctrl+C. It will instantly return to the input prompt.
I might be wrong that tokio::signal cannot do that, and if so, I apologize. But it doesn't appear so from your description.
Also, I have the same sort of code in my new project to turn signals into an event stream in C.
Okay, so I didn't say a release at first, but I meant to. That's only fair.
Anything built without the -a option to configure.sh is "the program." That's the vast majority. You can try the library too, but there is that one mistake you already know about. I don't think there are any others though.
And again, even with the things you all have found that are in random commits, it doesn't really matter; Rust isn't completely memory safe either. It's close, but not quite.
You did not say anything of the sort.
>But I also said to find one in the program, not the library.
You did not say anything of the sort.
You said:
>>The code is my `bc`. [1]
>>Find a memory bug, any memory bug, in my `bc` after 1.0.
>>[1]: https://git.yzena.com/gavin/bc
But okay, let's acknowledge the moved goalposts.
>I issue that challenge again: find a memory bug in the `bc` or `dc` program in a release after 1.0.
Tell me what subset of the repo named "bc" you consider to be "the program"
>Oh, and the double-free with `SIGINT`? Rust isn't going to help you much there. Signals are not part of Rust's model.
Crates like tokio::signal allow a signal to be converted to a stream of events, which can be handled along with any other events in the program, instead of interrupting the current fn in the middle and necessitating longjmp shenanigans. Since the existing stack is not interrupted in any special way, dtors fire as they're supposed to.