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=0ef849cb84650705ffc840a...
http://git.kernel.org/?p=git/git.git;a=blob;f=builtin-mailinfo.c;h=a50ac2256cdbacd76ed...

Regards,
Markus

--

[ message continues ]

What is the likelihood for those function calls to actually fail?


Nicolas
--

[ message continues ]

Do you know the probability for failed memory allocations?

Would you like to care for error codes from all Pthread function calls?

Regards,
Markus
--

[ message continues ]

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
--

[ message continues ]

Would you like to support software environments that work without a


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

Regards,
Markus
--

[ message continues ]

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

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

If you never notice, then that's a good thing, right? :)

Avery
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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

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

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
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.
--

[ message continues ]

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.

I do not want to prove this so far because return value ignorance might
be a common and well-known (bad) coding practice.

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

I would not say never. - Exceptional situations are usually expected to

The efforts for complete error code checking can be reduced by a mixture

It takes a bit more time to become comfortable with evolving software
technologies.

Regards,
Markus
--

[ message continues ]