Instead of checking if one of the TimeKeeper fields is 0 on every
operation (which adds overhead and protects only in the case of an
incoherent instantiation of the struct), add a new struct TimeKeeperSafe
that panics when created with bad values.
It is still possible that a developer can make a mistake and manually
initialize a TimeKeeper with bad values or else set its fields to bad
values. For now, we will accept this risk as it is not present in the
codebase.
Added simple checks for division by zero in arithmetic operations in
util/time.rs
Added a unit test to check that a TimeKeeper with values of 0 in its
fields can call its methods without panicking.
This issue was discovered by fuzzing.
Change the `unimplemented()!` panic macro to error handling that informs
the user that using Literals and Functions in nested function calls is
not yet supported. This should be a slightly more friendly developer
experience. Changing this from a panic to an error allows us to continue
with further fuzzing.
This issue was discovered with fuzzing.
Panic 1: It was possible to assign a variable to a function/opcode with
no return type. This caused a index-out-of-bounds panic when the
analyzer attempted to access the first element of an empty vector of
return types. The analyzer now presents an error when a .zk author
attempts to assign a variable to an opcode that has no return types.
Panic 2: There was an index-out-of-bounds panic when performing
verification on Literals that were passed to Opcodes that use Array
types as their arguments. This was fixed by pasting the validation code
from the Variable verfication section which handles Arrays properly.
(Refactoring should be done to reduce duplication here.)
These issues were found via fuzzing
Panic 1: If the size of the vector of tokens passed to
`check_section_structure` is less than 2, the parser tells
the author that there are not enough valid tokens in the section.
Panic 2: Very large values of k will result in integer overflow when the
value is larger than the type's MAX_SIZE. This causes the existing k <=
16 check to succeed but it actually shouldn't. In debug/fuzzing
contexts, Rust panics. In production, this will not occur.
Panic 3: If invalid/unimplemented characters appear in an argument to a function, the
parser panicked when it hit `unimplemented!()`. Now it tells the author
that this character cannot be used in an argument to a function.
Add error handling for the parser logic. Both of these issues were found
via fuzzing.
Fix Panic 1: instead of panicking via unwrap() when analyzing the namespace,
the parser displays an error message informing the .zk file author
that they need to add a namespace.
Fix Panic 2: if the length of the `tokens` vector is 0, the parser
now displays an error saying so.
Create a fuzz harness to test the ./zkas binary compilation process. The
whole pipeline is tested: Lexer, Parser, Compiler, Analyzer. This is
performed by copying the relevant code from bin/zkas/src/main.rs.
Testing the entire pipeline like this is not very efficient in terms of
fuzzing cycles but on the other hand it is a quick-and-dirty way to find
results. It also benefits from testing the actual inputs to the binary
in the way it's expecting, rather than checking each of the components
in a piecemeal way using interfaces that aren't expected to be exposed
anyway.
* zkas: Add error for missing semicolons
Fixed a parser bug where it would pass invalid statements to the
compiler which resulted in a panic.
Added error handling in the parser when a semicolon is missing. The
error message suggest to the dev to add a semicolon.
Also added more detail to the unreachable()! statement in the compiler
so that a darkfi dev can see what the erroneous StatementType was that
caused the panic.
Example errror cases:
```
<statement> <statement>;
```
and
```
<statement>
<statement>;
```
To test: remove a semicolon from example/simple.zk and run ./zkas
example/simple.zk
* add code comment to explain
---------
Co-authored-by: y <y>
With these changes, BlockInfo now represents a wrapper over Block, as it becomes constant/final in terms of structure. All extra data based on block versions go to BlockInfo, and their storage is handled accordingly.
