Hi Core Electronics,
Very low priority and happy to have the issue closed with no action. This is mostly just an observation and question.
I just happened to notice an unused variable.
In smbus_i2c_read on line 152 here: https://github.com/CoreElectronics/CE-PiicoDev-Unified/blob/main/PiicoDev_Unified.py#L152
ret_val is set to 0. However, ret_val is not updated anywhere else and on line 161 there is a conditional that checks ret_val in a statement that will always be true (since ret_val is never modified)
This function will always return 0 as a result. Rather than return a value, the function works by mutating the argument data_p.
Are my observations correct? Is there a reason for these functions to return 0 as opposed to not having a return statement? I understand in C that 0 returns are common to indicate no error code, in this case no error code is processed so a "return 0" at the end or even just no return statement can save some bytes and prevent someone thinking that the return value has meaning.
Cheers,
Gary
Hi Core Electronics,
Very low priority and happy to have the issue closed with no action. This is mostly just an observation and question.
I just happened to notice an unused variable.
In smbus_i2c_read on line 152 here: https://github.com/CoreElectronics/CE-PiicoDev-Unified/blob/main/PiicoDev_Unified.py#L152
ret_val is set to 0. However, ret_val is not updated anywhere else and on line 161 there is a conditional that checks ret_val in a statement that will always be true (since ret_val is never modified)
This function will always return 0 as a result. Rather than return a value, the function works by mutating the argument data_p.
Are my observations correct? Is there a reason for these functions to return 0 as opposed to not having a return statement? I understand in C that 0 returns are common to indicate no error code, in this case no error code is processed so a "return 0" at the end or even just no return statement can save some bytes and prevent someone thinking that the return value has meaning.
Cheers,
Gary