vendor/bc: import version 6.1.0
This is a production release that fixes a discrepancy from the bc
standard, a couple of memory bugs, and adds new features.
The discrepancy from the bc standard was with regards to the behavior
of the quit command. This bc used to quit whenever it encountered quit
during parsing, even if it was parsing a full file. Now, bc only quits
when encountering quit after it has executed all executable statements
up to that point.
This behavior is slightly different from GNU bc, but users will only
notice the difference if they put quit on the same line as other
statements.
The first memory bug could be reproduced by assigning a string to a
non-local variable in a function, then redefining the function with
use of the same non-local variable, which would still refer to a
string in the previous version of the function.
The second memory bug was caused by passing an array argument to the
asciify() built-in function. In certain cases, that was wrongly
allowed, and the interpreter just assumed everything was correct and
accessed memory. Now that arrays are allowed as arguments (see below),
this is not an issue.
The first feature was the addition of the is_number() built-in
function (u in dc) that returns 1 if the runtime argument is a number
and 0 otherwise.
The second feature was the addition of the is_string() built-in
function (t in dc) that returns 1 if the runtime argument is a string
and 0 otherwise.
These features were added because I realized that type-checking is
necessary now that strings can be assigned to variables in bc and
because they've always been assignable to variables in dc.
The last added feature is the ability of the asciify() built-in
function in bc to convert a full array of numbers into a string. This
means that character-by-character printing will not be necessary, and
more strings than just single-character ones will be able to be
created.
2023-01-28 19:59:18 +00:00
|
|
|
# Memory Bugs
|
|
|
|
|
|
|
|
|
|
This is a list of all of the memory bugs that were found in *released* versions
|
|
|
|
|
of `bc`, `dc`, or `bcl`. (Non-released commits with memory bugs do not count.)
|
|
|
|
|
|
|
|
|
|
I made this list for two reasons: first, so users can know what versions of
|
|
|
|
|
`bc`, `dc`, and `bcl` have vulnerabilities, and two, I once had a perfect record
|
|
|
|
|
and then found a couple, but forgot and claimed I still had a perfect record
|
|
|
|
|
right after, which was embarrassing.
|
|
|
|
|
|
|
|
|
|
This list is sorted by the first version a bug exists in, not the last it
|
|
|
|
|
existed in.
|
|
|
|
|
|
2023-01-28 20:06:20 +00:00
|
|
|
* In versions `1.1.0` until `6.2.0` (inclusive) of `bc` and `dc`, there is a
|
|
|
|
|
out of bounds read and write in history when pressing ctrl+r (or any other
|
|
|
|
|
unused letter) then inserting two characters.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.2.1`.
|
|
|
|
|
|
vendor/bc: import version 6.1.0
This is a production release that fixes a discrepancy from the bc
standard, a couple of memory bugs, and adds new features.
The discrepancy from the bc standard was with regards to the behavior
of the quit command. This bc used to quit whenever it encountered quit
during parsing, even if it was parsing a full file. Now, bc only quits
when encountering quit after it has executed all executable statements
up to that point.
This behavior is slightly different from GNU bc, but users will only
notice the difference if they put quit on the same line as other
statements.
The first memory bug could be reproduced by assigning a string to a
non-local variable in a function, then redefining the function with
use of the same non-local variable, which would still refer to a
string in the previous version of the function.
The second memory bug was caused by passing an array argument to the
asciify() built-in function. In certain cases, that was wrongly
allowed, and the interpreter just assumed everything was correct and
accessed memory. Now that arrays are allowed as arguments (see below),
this is not an issue.
The first feature was the addition of the is_number() built-in
function (u in dc) that returns 1 if the runtime argument is a number
and 0 otherwise.
The second feature was the addition of the is_string() built-in
function (t in dc) that returns 1 if the runtime argument is a string
and 0 otherwise.
These features were added because I realized that type-checking is
necessary now that strings can be assigned to variables in bc and
because they've always been assignable to variables in dc.
The last added feature is the ability of the asciify() built-in
function in bc to convert a full array of numbers into a string. This
means that character-by-character printing will not be necessary, and
more strings than just single-character ones will be able to be
created.
2023-01-28 19:59:18 +00:00
|
|
|
* In versions `3.0.0` until `6.0.1` (inclusive) of `bc` and `dc`, there is a
|
|
|
|
|
double-free on `SIGINT` when using command-line expressions with `-e` and
|
|
|
|
|
`-f`. This was caused by not properly ending a jump series.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.0.2`.
|
|
|
|
|
|
|
|
|
|
* In versions `5.0.0` until `6.0.4` (inclusive) of `bc`, there is an
|
|
|
|
|
out-of-bounds access if a non-local (non-`auto`) variable is set to a string
|
|
|
|
|
with `asciify()`, then the function is redefined with a use of the same
|
|
|
|
|
non-local variable.
|
|
|
|
|
|
|
|
|
|
This happened because strings were stored per-function, and the non-local
|
|
|
|
|
variable now had a reference to the string in the old function, which could be
|
|
|
|
|
at a higher index than exists in the new function. Strings are stored globally
|
|
|
|
|
now, and they are *not* freed once not used.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.1.0`.
|
|
|
|
|
|
|
|
|
|
* In versions `5.0.0` until `6.0.4` (inclusive) of `bc`, there is another
|
|
|
|
|
out-of-bounds access if an array is passed to the `asciify()` built-in
|
|
|
|
|
function as the only argument. This happened because arrays are allowed as
|
|
|
|
|
function arguments, which allowed them to be used as arguments to `asciify()`,
|
|
|
|
|
but they should not have been allowed. However, since they were, the
|
|
|
|
|
`asciify()` code tried to access an argument that was not there.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.1.0`.
|
|
|
|
|
|
2023-01-28 20:02:27 +00:00
|
|
|
* In version `6.0.0` of `bcl`, there are several uses of initialized data that
|
vendor/bc: import version 6.1.0
This is a production release that fixes a discrepancy from the bc
standard, a couple of memory bugs, and adds new features.
The discrepancy from the bc standard was with regards to the behavior
of the quit command. This bc used to quit whenever it encountered quit
during parsing, even if it was parsing a full file. Now, bc only quits
when encountering quit after it has executed all executable statements
up to that point.
This behavior is slightly different from GNU bc, but users will only
notice the difference if they put quit on the same line as other
statements.
The first memory bug could be reproduced by assigning a string to a
non-local variable in a function, then redefining the function with
use of the same non-local variable, which would still refer to a
string in the previous version of the function.
The second memory bug was caused by passing an array argument to the
asciify() built-in function. In certain cases, that was wrongly
allowed, and the interpreter just assumed everything was correct and
accessed memory. Now that arrays are allowed as arguments (see below),
this is not an issue.
The first feature was the addition of the is_number() built-in
function (u in dc) that returns 1 if the runtime argument is a number
and 0 otherwise.
The second feature was the addition of the is_string() built-in
function (t in dc) that returns 1 if the runtime argument is a string
and 0 otherwise.
These features were added because I realized that type-checking is
necessary now that strings can be assigned to variables in bc and
because they've always been assignable to variables in dc.
The last added feature is the ability of the asciify() built-in
function in bc to convert a full array of numbers into a string. This
means that character-by-character printing will not be necessary, and
more strings than just single-character ones will be able to be
created.
2023-01-28 19:59:18 +00:00
|
|
|
have the same root cause: I forgot to call `memset()` on the per-thread global
|
|
|
|
|
data. This is because the data used to be *actually* global, which meant that
|
|
|
|
|
it was initialized to zero by the system. This happened because I thought I
|
|
|
|
|
had properly hooked Valgrind into my `bcl` tests, but I had not.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.0.1`.
|
2023-02-24 22:14:58 +00:00
|
|
|
|
|
|
|
|
* In version `6.0.0` until `6.2.4` (inclusive) of `bcl`, there is a possible
|
|
|
|
|
use-after-free if `bcl_init()` fails.
|
|
|
|
|
|
|
|
|
|
The first version without this bug is `6.2.5`.
|