Return code is 0 even on failure

[msalau]

Return code is 0 even on failure

[msalau]

Hi @bicyclesonthemoon

Thanks for pointing this out!
My view on unique return codes somewhat differs from yours. I think that a caller should not care much about the reason of failure, rather than the fact of failure. I.e. an automated tool has no means to correct an error.

If you feel that this feature if absolutely necessary, I'll add it. But in mean time I've fixed the code in my way :) See the v0.6.1 tag.

Regards,
Maksim.

[bicyclesonthemoon]

I tested 0.6.1.
Indeed it is not needed to have an individual error code for each situation.
Like you did with EINVAL, EIO, ECANCELED is enough.
The expected use case is that rl78flash will be called from an automatic sequence which will be interrupted on error. The operator will be able to see the output of stdout and stderr and see what happened.

It works ok - I'm not able to find any situation when an error occurs but code is 0. Good.

Small remark:
When an argument like -b -m or -t is used incorrectly (wrong value or something) then usage is written to stdout and error code is returned but nothing is written to stderr that parameter was used incorrectly.

Also when running rl78flash -h then usage is displayed and error code is returned.
I think that if -h parameter was used then showing the help was the expected behavior and shouldn't be treated as an error.
How about something like this:
case 'h':
case '?':
printf("%s", usage);
return 0;
default:
printf("%s", usage);
return ECANCELED;

[msalau]

Hi @bicyclesonthemoon

Thanks for testing!

Small remark:
When an argument like -b -m or -t is used incorrectly (wrong value or something) then usage is written to stdout and error code is returned but nothing is written to stderr that parameter was used incorrectly.

Ok. I'll fix this.

Also when running rl78flash -h then usage is displayed and error code is returned.
I think that if -h parameter was used then showing the help was the expected behavior and shouldn't be treated as an error.

I agree, that showing the help is not a error case. But help is usually requested by a user, not a script.
So returning non-zero exit code to a user in an interactive shell is not an issue, I believe. But what if -h sneaks into the argument list in a non-interactive script? If the app returns 0, then the script will consider flashing successful, but rl78flash exited without any flashing done. So this is why I decided to return ECANCELED even on help request. If a user wants to get help message in a script, he can always ignore the exit code to make this action explicit.

Regards,
Maksim.

[bicyclesonthemoon]

I agree, that showing the help is not a error case. But help is usually requested by a user, not a script.
So returning non-zero exit code to a user in an interactive shell is not an issue, I believe. But what if -h sneaks into the argument list in a non-interactive script? If the app returns 0, then the script will consider flashing successful, but rl78flash exited without any flashing done. So this is why I decided to return ECANCELED even on help request. If a user wants to get help message in a script, he can always ignore the exit code to make this action explicit.

Ok, this makes sense. I understand it.
In fact, my wrapper for rl78flash which my tools will use doesn't even give the possibility to select -h.