Hello all,
I sent this patch some days ago, but I saw that my e-mail client
took the bluez-users address. Hopes to not annoy you sending it
again (to the right place now).
rfcomm program does not return proper error codes to the environment,
this makes hard to use it from a shell script or from another program.
Here goes a patch to fix it. I didn't have much time to test it, so
any feedback is welcome.
- Changes functions to return -1 on error and 0 on success
- Adds missing error checks
- Adds missing error messages
- Fixes rfcomm exit() return codes
rfcomm/main.c | 192
+++++++++++++++++++++++++++++++++++++++-------------------
1 files changed, 131 insertions(+), 61 deletions(-)
--
Luiz Fernando N. Capitulino
Hello Marcel,
Marcel Holtmann wrote:
> lets keep it using "exit(1)". It is an historic issue. Send a patch for
> the few cases we did it wrong.
Okay, it's attached. Note that:
1) Some functions returns -1 on error, I didn't change it
2) Create all devices and release all devices returns success if all devices
could be created (or released), otherwise it returns error (IOW, if we get
an error to create or release at least one device, the program returns error)
3) I've added some missing checks
4) If you enter with an unknown parameter it does 'exit(1)' instead of
'exit(0)', because it's an error.
rfcomm/main.c | 135 ++++++++++++++++++++++++++++++++++++++++------------------
1 files changed, 95 insertions(+), 40 deletions(-)
PS: The parameters for raw terminal mode (-r) and configfile (-f)
are not documented, I think a patch for it doesn't pay off. :)
--
Luiz Fernando N. Capitulino
Hi Luiz,
> > I don't see the advantages from changing "exit(1)" into "return -1".
> > This doesn't fix program error codes.
>
> Sure, but actually, the functions are returning -1, while main()
> checks this return value and does return 'exit(1)' on error. So, this
> patch fixes the error codes.
>
> I guess you're speaking about some changes from 'exit(1)' to 'return -1'
> I've made. I did that change, as I changed some 'return -errno' or added
> proper return value to void functions.
>
> I saw that most programs (but not all) in the utils package calls exit(1)
> directly in the functions when an error happens. IMHO, making functions
> return -1 (instead of aborting directly) is pretty better because: 1) system
> calls and libc follows that standard; 2) it's easier to copy and paste functions
> in other programs; and 3) your program has only one exit point (in main()).
>
> But of course, maybe it's not an issue, and if you wants to, I can change it to
> exit in functions directly.
lets keep it using "exit(1)". It is an historic issue. Send a patch for
the few cases we did it wrong.
And btw I support people copying the code, but I also like to see that
people understand what the code does. If they have to change "exit(1)"
to have proper return values in their own code, they at least looked at
the code once.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
Marcel Holtmann wrote:
> Hi Luiz,
>
>
>>I sent this patch some days ago, but I saw that my e-mail client
>>took the bluez-users address. Hopes to not annoy you sending it
>>again (to the right place now).
>>
>>rfcomm program does not return proper error codes to the environment,
>>this makes hard to use it from a shell script or from another program.
>>
>>Here goes a patch to fix it. I didn't have much time to test it, so
>>any feedback is welcome.
>>
>>- Changes functions to return -1 on error and 0 on success
>>- Adds missing error checks
>>- Adds missing error messages
>>- Fixes rfcomm exit() return codes
>
>
> I don't see the advantages from changing "exit(1)" into "return -1".
> This doesn't fix program error codes.
Sure, but actually, the functions are returning -1, while main()
checks this return value and does return 'exit(1)' on error. So, this
patch fixes the error codes.
I guess you're speaking about some changes from 'exit(1)' to 'return -1'
I've made. I did that change, as I changed some 'return -errno' or added
proper return value to void functions.
I saw that most programs (but not all) in the utils package calls exit(1)
directly in the functions when an error happens. IMHO, making functions
return -1 (instead of aborting directly) is pretty better because: 1) system
calls and libc follows that standard; 2) it's easier to copy and paste functions
in other programs; and 3) your program has only one exit point (in main()).
But of course, maybe it's not an issue, and if you wants to, I can change it to
exit in functions directly.
Thank you for reveiwing my patches,
--
Luiz Fernando N. Capitulino
Hi Luiz,
> I sent this patch some days ago, but I saw that my e-mail client
> took the bluez-users address. Hopes to not annoy you sending it
> again (to the right place now).
>
> rfcomm program does not return proper error codes to the environment,
> this makes hard to use it from a shell script or from another program.
>
> Here goes a patch to fix it. I didn't have much time to test it, so
> any feedback is welcome.
>
> - Changes functions to return -1 on error and 0 on success
> - Adds missing error checks
> - Adds missing error messages
> - Fixes rfcomm exit() return codes
I don't see the advantages from changing "exit(1)" into "return -1".
This doesn't fix program error codes.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel