Fix suspicious pointer scaling

[jserv]

Tracking issue for:

• https://github.com/sysprog21/rv32emu/security/code-scanning/26

src/emulate.c:713
This pointer might have type unsigned long (size 8), but this pointer arithmetic is done with type uint32_t * (size 4).
Pointer arithmetic in C and C++ is automatically scaled according to the size of the data type. For example, if the type of p is T* and sizeof(T) == 4 then the expression p+1 adds 4 bytes to p. This can cause a buffer overflow condition if the programmer forgets that they are adding a multiple of sizeof(T), rather than a number of bytes.
This query finds pointer arithmetic expressions where it appears likely that the programmer has forgotten that the offset is automatically scaled.
Common Weakness Enumeration: CWE-468.

• https://github.com/sysprog21/rv32emu/security/code-scanning/27

src/emulate.c:717

• https://github.com/sysprog21/rv32emu/security/code-scanning/28

src/emulate.c:721

[jserv]

This issue is related to #89 in preparation for CodeQL analysis.

[TheCloudlet]

Hi,
I have looked into the code.

The type for &rv->csr_cycle is uint64_t *
We cast the pointer type into uni32_t*, i.e. (unit32_t)* &rv->csr_cycle
then increment the pointer by sizeof(unit32_t).

It looks good to me.

[jserv]

The expression sizeof(unit32_t) is always 4. Write elegant code.

[jserv]

GitHub code scanning is powered by CodeQL analysis engine.

LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine ⚙️ that powers LGTM.com. For more information, please check out our post on the GitHub blog.