Completion of error handling
Hello,
I would like to point out that some checks for return codes are missing in the source files.
Examples:
Would you like to add more error handling for return values from "pthread_mutex_init" like in the function "start_threads" and from "fprintf" in the function "output_header_lines"?
http://git.kernel.org/?p=git/git.git;a=blob;f=builtin-grep.c;h=0ef849cb84650705ffc840aed8a3fcedbeb48f9a;hb=HEAD#l224
http://git.kernel.org/?p=git/git.git;a=blob;f=builtin-mailinfo.c;h=a50ac2256cdbacd76ed44a50804212be07f949db;hb=HEAD#l935
Regards,
Markus
Quoted 6 lines · Markus Elfring
Hello,
I would like to point out that some checks for return codes are missing in the source files.
Examples:
Would you like to add more error handling for return values from "pthread_mutex_init" like in the function "start_threads" and from "fprintf" in the function "output_header_lines"?
What is the likelihood for those function calls to actually fail?
Nicolas
Quoted 2 lines
What is the likelihood for those function calls to actually fail?
Do you know the probability for failed memory allocations?
Would you like to care for error codes from all Pthread function calls?
Regards,
Markus
Quoted 6 lines · Markus Elfring
Quoted 2 lines
What is the likelihood for those function calls to actually fail?
Do you know the probability for failed memory allocations?
Would you like to care for error codes from all Pthread function calls?
Not necessarily. At least on Linux, most of those functions simply cannot fail. There is just no dynamic memory allocation involved. All other errors are normally due to bad code.
Nicolas
Quoted 2 lines
At least on Linux, most of those functions simply cannot fail.
Would you like to support software environments that work without a famous out-of-memory killer?
Quoted 2 lines
There is just no dynamic memory allocation involved.
I find this opinion strange.
Quoted 2 lines
All other errors are normally due to bad code.
I suggest to avoid unchecked function calls.
Would you like to detect every error situation as early as possible?
Regards,
Markus
Quoted 5 lines · Markus Elfring
Quoted 1 line · Nicolas
At least on Linux, most of those functions simply cannot fail.
Would you like to support software environments that work without a famous out-of-memory killer?
In many cases on Linux systems, you don't get the OOM notification anyway until you try to *use* the memory, not at allocation time. So even checking the results of malloc() won't always save you (although *not* checking can make problems even worse).
However, for functions that can't allocate memory at all, it's extra pointless to worry about.
Quoted 3 lines
Quoted 1 line
There is just no dynamic memory allocation involved.
I find this opinion strange.
This isn't an opinion; because it's open source, you can actually look at the source code and find out that many system calls don't do memory allocation at all.
Avery
Quoted 6 lines
This isn't an opinion; because it's open source, you can actually look at the source code and find out that many system calls don't do memory allocation at all.
I agree to your view because you distinguish between the available software implementations here.
Are you also interested to complete error detection and corresponding exception handling?
Regards,
Markus
Quoted 8 lines · Markus Elfring
Quoted 3 lines
This isn't an opinion; because it's open source, you can actually look at the source code and find out that many system calls don't do memory allocation at all.
I agree to your view because you distinguish between the available software implementations here.
Are you also interested to complete error detection and corresponding exception handling?
I think if you can demonstrate actual situations where lack of error handling could cause:
a) user confusion; or
b) data loss/corruption
...then it will be easy to get people to accept your patches to fix the error handling. If you can't reproduce or at least describe such a case in detail, however, people probably won't be too excited about it. git developers seem to concentrate more on concrete problems than theoretical ones.
Avery
Quoted 5 lines
...then it will be easy to get people to accept your patches to fix the error handling.
You do not need to make assumptions about error situations. Please check all error codes.
Otherwise, it might not be noticed if anything unexpected went wrong.
Regards,
Markus
Quoted 6 lines · Markus Elfring
Quoted 2 lines
...then it will be easy to get people to accept your patches to fix the error handling.
You do not need to make assumptions about error situations. Please check all error codes.
Otherwise, it might not be noticed if anything unexpected went wrong.
If you never notice, then that's a good thing, right? :)
Avery
Quoted 4 lines
If you never notice, then that's a good thing, right? :)
Well, this depends on the kind of potential damage that will come from the ignorance of function return values.
It might hurt more when corresponding effects can not be ignorable any more because they became so obvious.
Regards,
Markus
Quoted 4 lines
What is the likelihood for those function calls to actually fail?
How do you think about the usual design choices that are described in the article "Exception Handling Alternatives" by Detlef Vollmann.
http://accu.org/index.php/journals/546
I propose to write pointcuts for all functions that can return values. Some corresponding error codes are checked already. But there a places in the source files with open issues for complete software robustness.
Are there any chances to encapsulate more cross-cutting concerns as reusable aspects?
Would you like to integrate tools like the following into your software development process?
- AspectC++
http://aspectc.org/
- ACC
http://research.msrg.utoronto.ca/ACC/Tutorial#A_Reusable_Aspect_for_Memory_All
- Coccinelle
http://coccinelle.lip6.fr/
Regards,
Markus
Quoted 9 lines · Markus Elfring
Quoted 4 lines
What is the likelihood for those function calls to actually fail?
How do you think about the usual design choices that are described in the article "Exception Handling Alternatives" by Detlef Vollmann.
http://accu.org/index.php/journals/546
That's an awful lot of text to read that's hardly relevant for a C program. Most of it regards newbie stuff about how to handle reporting an error when you can't use a C++ exception.
Quoted 5 lines
I propose to write pointcuts for all functions that can return values. Some corresponding error codes are checked already. But there a places in the source files with open issues for complete software robustness.
You keep on claiming that but haven't proven it in any way. If you could point out a real bug I'm very, very certain it would be fixed within 24 hours.
Quoted 8 lines
Are there any chances to encapsulate more cross-cutting concerns as reusable aspects?
Would you like to integrate tools like the following into your software development process?
- AspectC++
http://aspectc.org/
Git is written in C, not C++. Using aspectc++ would mean requiring the use of a C++ compiler, which git doesn't require today. That's one step backwards in portability which I seriously doubt the usefulness of aspectc++ can outweigh.
Now please stop trolling and find one of these bugs you keep talking about but never showing. We've made it painfully clear to you that we're interested in realworld problems rather than potential ones, so all this "use this model for development" just reeks of concept evangelism. No real engineer likes that, which is why you're facing such massive opposition on this list.
Signature · 7 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.
Quoted 5 lines
That's an awful lot of text to read that's hardly relevant for a C program. Most of it regards newbie stuff about how to handle reporting an error when you can't use a C++ exception.
I would like to quote a bit which shows the underlying issues with the used programming language.
"...
Exceptional events occur. But, since they are exceptional, they occur very rarely. This is exactly the problem with them. In programming courses you learn to always handle any possible event. But, in practice, most programmers just ignore them. If you look at this problem in detail, you see that these events are not ignored where they actually occur, but at some higher level.
..."
Quoted 2 lines
You keep on claiming that but haven't proven it in any way.
I do not want to prove this so far because return value ignorance might be a common and well-known (bad) coding practice.
https://www.securecoding.cert.org/confluence/display/seccode/EXP12-C.+Do+not+ignore+values+returned+by+functions
Quoted 3 lines
Git is written in C, not C++. Using aspectc++ would mean requiring the use of a C++ compiler, which git doesn't require today.
It would be nice if C++ exceptions could be used here because they can not be ignored by default. I guess that the tool "AspectC++" will also work with C constructs. Do you find the tool "AspeCt-oriented C compiler" more appealing?
Quoted 2 lines
Now please stop trolling and find one of these bugs you keep talking about but never showing.
I would not say never. - Exceptional situations are usually expected to appear seldom.
Quoted 3 lines
We've made it painfully clear to you that we're interested in realworld problems rather than potential ones, so all this "use this model for development" just reeks of concept evangelism.
The efforts for complete error code checking can be reduced by a mixture of function, class and advice libraries.
Quoted 3 lines
No real engineer likes that, which is why you're facing such massive opposition on this list.
It takes a bit more time to become comfortable with evolving software technologies.
Regards,
Markus