Check return codes everywhere

[GoogleCodeExporter]

Some checks for return codes are missing.

Examples:
Would you like to add more error handling for return values from
"apr_palloc" like in the function "mrcp_parser_create" (revision 1388) and
from "printf" in the function "cmdline_process" (revision 622)?
http://code.google.com/p/unimrcp/source/browse/trunk/libs/mrcp/control/src/mrcp_
stream.c
http://code.google.com/p/unimrcp/source/browse/trunk/platforms/unimrcp-server/sr
c/uni_cmdline.c

Original issue reported on code.google.com by Markus.E...@web.de on 31 Jan 2010 at 5:08

[GoogleCodeExporter]

I agree that return code checking is a good and probably necessary practice. 
However,
checking return codes everywhere doesn't seem reasonable enough to me. At least 
I
don't check return values for memory allocations. I know it's debatable. 
Perhaps, I'd
prefer to catch C++ exceptions instead, when/if available. Although "printf" is 
used
only in a couple of console applications, it's still not so clear what one 
should do
if "printf" fails.
Any thoughts?

Original comment by achalo...@gmail.com on 1 Feb 2010 at 11:07

[GoogleCodeExporter]

I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?

Would you like to reduce the efforts for error code checking by an exception 
class
hierarchy?
http://dietmar-kuehl.de/mirror/c++-faq/exceptions.html#faq-17.1
http://cexcept.sourceforge.net/

Original comment by Markus.E...@web.de on 1 Feb 2010 at 11:38

[GoogleCodeExporter]

Yes, I prefer to detect and fix potential errors as early as possible, 
preferably
before deployment and there are appropriate tools which usually are very 
helpful for
software validation.

Sometimes I indeed prefer to use C++ exceptions. The issue is this project is 
written
in pure C.
BTW, What is your goal? Where are you going to use the project?

Original comment by achalo...@gmail.com on 1 Feb 2010 at 2:02

[GoogleCodeExporter]

The completion of error detection and corresponding exception handling is a 
goal.

I would appreciate a clarification which function calls need to be kept as C 
style
interfaces to provide the portable ABI and which of them could use more C++ 
features
for their implementations.

Are there any chances to integrate higher level programming tools like 
AspectC++ and
ACC into the software development process here?
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All
http://aspectc.org/

Original comment by Markus.E...@web.de on 1 Feb 2010 at 3:00

[GoogleCodeExporter]

The project as a whole has been written in C. There is a sample application 
named
"umc", which is in C++ to demonstrate client stack can be utilized by both C 
and C++
applications. Usage of plain C allows binding from other higher level languages,
interpreters.

Integration of AspectC into the software development process probably is a 
worthy
option, but I don't think I can devote corresponding time for it at least in
foreseeable future.

Original comment by achalo...@gmail.com on 1 Feb 2010 at 8:08

[GoogleCodeExporter]

I am interested in an improved mixture of C and C++ constructions. I would like 
to
point out that while a C API might be a safe way to provide a portable 
application
binary interface the function implementations can also contain C++ instructions.

Thanks for your basic acceptance of the suggested tool.

AspectC++ can help better to implement cross-cutting concerns as advices. 
Pointcuts
would filter out unchecked function calls for example. I am curious how many 
manual
coding can be moved to a couple of automatic advice applications.

Original comment by Markus.E...@web.de on 1 Feb 2010 at 10:10

[GoogleCodeExporter]

Summarizing the discussion, I agree with all the mentioned points and also 
suggested
tool looks helpful. However, I'm afraid it'd not be possible to look into this 
closer
at least in the foreseeable future.

Original comment by achalo...@gmail.com on 10 Mar 2010 at 6:41

• Changed state: WontFix