Concern with overflow and the use of signed integers regarding the Lyra2.c file about garlicoin

[ryan-shaw]

There is no concern, if you read the call stack you will see it can't get an invalid int. If int64_t was always a concern it wouldn't have been added.

[ezquire]

is relying on the call stack beneficial for efficiency? I'm still just a student so I'm trying to gauge why you wouldn't just change it to a unsigned int, does it make more sense to restrict the functions parameters instead of relying on the call stack to return a legitimate value? (again im a student so bear with me if what i'm saying makes no sense)

[ryan-shaw]

Honestly, I don't know, it's not my code- it's from the reference lyra2 implementation. You'd have to ask them why they chose this.

[ezquire]

the code I diffed is from the lyra2.c core implementation, so maybe there was some change between the docs? I know its annoying but can you shoot me that link to the ref docs before we call this issue closed?

[ryan-shaw]

I'll find tomorrow, it's later here.

[Bogden]

https://github.com/vertcoin/vertcoin-old/blob/master/src/Lyra2RE/Lyra2.c#L46

Quick reference to the vertcoin Lyra2, for comparison

[ryan-shaw]

Well that's vertcoins implementation not the reference implementation

[ryan-shaw]

This is a none issue. The function you are referring can't be passed anything other than 32 bytes look here and you will see why https://github.com/GarlicoinOrg/Garlicoin/blob/master/src/crypto/allium/allium.c#L59.