Memory-safe, clean implementation of classic Posix "BC" calculator
1–10 of 55 posts
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#2The title reminds me of the adds for "Shen Yun China Before Communism" which begs the question: ok what about life after communism ... where's the song and dance show about that?
Similarly, if this is the memsafe bc, where's the wow it leaks memory like a 1980s rock ballad bc code?
Hint: one has an answer, and the other has really never been on the radar safe or no.
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#3Lost as to why there is a tests folder yet the test function marked with the #[test] attribute is being added to /src: https://github.com/rustcoreutils/posixutils-rs/pull/132/comm... edit: Since the change was to the grammar saved in a separate .pest file, which is separated from the procedural code, then would that make the test an integration rather than a unit test as the "parse_program" function is public?
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#4Lost as to why there is a tests folder yet the test function marked with the #[test] attribute is being added to /src: https://github.com/rustcoreutils/posixutils-rs/pull/132/comm... edit: Since the change was to the grammar saved in a separate .pest file, which is separated from the procedural code, then would that make the test an integration rather than a unit test as the "parse_program" function is public?
In Rust, unit tests are marked using the #[test] attribute and typically live alongside the code under test.
Integration tests live under a top-level “tests” folder - in this case, you’ll see that the “tests” directory contains test that call the CLI command and verify its output.
See: https://doc.rust-lang.org/book/ch11-03-test-organization.htm...
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#5Lost as to why there is a tests folder yet the test function marked with the #[test] attribute is being added to /src: https://github.com/rustcoreutils/posixutils-rs/pull/132/comm... edit: Since the change was to the grammar saved in a separate .pest file, which is separated from the procedural code, then would that make the test an integration rather than a unit test as the "parse_program" function is public?
In Rust, unit tests are marked using the #[test] attribute and typically live alongside the code under test. Integration tests live under a top-level “tests” folder - in this case, you’ll see that the “tests” directory contains test that call the CLI command and verify its output. See: https://doc.rust-lang.org/book/ch11-03-test-organization.htm...
[deleted]
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#6As the author of the default bc in macOS and FreeBSD, good luck.
Also, while mine is in C, I have tried very hard to eliminate all memory safety bugs, and I think I have done pretty well.
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#7As the author of the default bc in macOS and FreeBSD, good luck. Also, while mine is in C, I have tried very hard to eliminate all memory safety bugs, and I think I have done pretty well. https://git.gavinhoward.com/gavin/bc/
> good luck.
Do you see this as an unexpectedly challenging task? If so, what do you think makes it challenging?
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#8As the author of the default bc in macOS and FreeBSD, good luck. Also, while mine is in C, I have tried very hard to eliminate all memory safety bugs, and I think I have done pretty well. https://git.gavinhoward.com/gavin/bc/
> good luck. Do you see this as an unexpectedly challenging task? If so, what do you think makes it challenging?
Not terribly challenging, but harder than expected.
The reason: parsing.
The bc language is poorly designed for a REPL, which it needs to handle.
I got sick of fixing parse bugs, though, and my source code got a sarcastic comment: https://git.gavinhoward.com/gavin/bc/src/commit/4b83bf07b97f...
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#9bc(1) is nice to have, but —for my purposes— less useful than dc(1), because it doesn't generate arbitrary binary output.
Re: Memory-safe, clean implementation of classic Posix "BC" calculator
#10bc (1) is nice to have, but —for my purposes— less useful than dc (1), because it doesn't generate arbitrary binary output.
If you're talking about the `P` command, I added an extension to my bc to do the same thing. It's the `stream` statement.
But it's probably still more convenient in dc.