[x/programs] Improve overflow checks

[samliok]

This PR improves overflow handling and generally improves developer UX by allowing not restricting Call params sent to the Program to be uint64.

[samliok]

I think we should refactor how we handle uint64 & int64. I updated the PR to reduce our risk of overflow and allowing greater functionality with signed integers.

In the codebase we were restricting call params to our wasm programs to only uint64 types. This approach doesn't make sense because

• wasm does not have unsigned integer types and will just convert our params into either i32 or i64
• this artificially limits us from passing negative values into wasm.
• potential unchecked overflow errors as max uint64 > max int64

Because of WASM's nature we should default to using int64.

[samliok]

In addition to #429 we need to make sure our wrapper u64 does not exceed MaxInt64

[hexfusion]

This makes sense one last nit 🙏

• ensure safe conversion from int64 to int32

[hexfusion]

very close!

[samliok]

@hexfusion should I also check the return value for overflow in this function?

pub extern "C" fn alloc(len: usize) -> *mut u8 {

[hexfusion]

@hexfusion should I also check the return value for overflow in this function?

pub extern "C" fn alloc(len: usize) -> *mut u8 {

Well we should ensure that all the conversions are safe for Alloc. I think we still need to check uint64 -> int32 here in golang? Not sure how practical that overflow would be but doesn't hurt.

hypersdk/x/programs/runtime/memory.go

Lines 77 to 82 in 8a71911

	func (m *memory) Alloc(length uint64) (uint64, error) {
	fn, err := m.client.ExportedFunction(AllocFnName)
	if err != nil {
	return 0, err
	}
	result, err := fn.Call(m.client.Store(), int32(length))

the export to alloc takes an i32 as param and usize can't be negative so I am not sure if something strange could happen there I suppose you could check against i32::MAX but it might not be nessisary.

[richardpringle]

🚀