Omniscia Glimpse Audit
GLMS_BSC Static Analysis Findings
GLMS_BSC Static Analysis Findings
GLM-01S: Illegible Value Literal
Type | Severity | Location |
---|---|---|
Code Style | Informational | GLMS_BSC.sol:L28 |
Description:
The _totalSupply
variable is assigned to a literal value with multiple digits with no discerning character between them.
Example:
24constructor() {25 _name = "Glimpse";26 _symbol = "GLMS";27 _decimals = 18;28 _totalSupply = 360000000 * 10 ** 18;29 _balances[_msgSender()] = _totalSupply;30 31 emit Transfer(address(0), _msgSender(), _totalSupply);32}
Recommendation:
We strongly recommend the underscore (_
) character to be introduced in between units (i.e. 360000000
becomes 360_000_000
) to increase the legibility of the codebase as the underscore character is ignored in numeric declarations by the compiler.
Alleviation:
The number is now depicted with the underscore (_
) separator thus rendering the value legible.
GLM-02S: Variable Shadowing
Type | Severity | Location |
---|---|---|
Language Specific | Informational | GLMS_BSC.sol:L102-L104, L207-L213 |
Description:
The linked functions both declare an owner
input argument whereas a contract-level declaration with the same name exists.
Example:
207function _approve(address owner, address spender, uint256 amount) internal {208 require(owner != address(0), "BEP20: approve from the zero address");209 require(spender != address(0), "BEP20: approve to the zero address");210 211 _allowances[owner][spender] = amount;212 emit Approval(owner, spender, amount);213}
Recommendation:
We strongly advise the arguments to be renamed to avoid variable shadowing occuring.
Alleviation:
The allowance
and _approve
arguments were properly prefixed with an underscore (_
) to prevent the naming colission from occuring.