Completion of error handling

[elfring]

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• fprintf ⇒ main_version
• pthread_mutex_init ⇒ thrqueue_new
• strdup ⇒ proxyspec_parse

[droe]

Makes sense; feel free to submit patches or send pull requests.

[elfring]

I suggest to avoid ignorance of return values a bit more.

Are you interested to apply aspect-oriented software development?
How do you think about to encapsulate error detection and corresponding exception handling as a reusable aspect in your software?

[droe]

SSLsplit was written to scratch an itch, not to win a software engineering competition :)

I do appreciate specific bug reports about unchecked error conditions and I will eventually work through them; in the meantime you are free to submit patches.

[elfring]

I try to check the corresponding change acceptance before increasing software development efforts for a preferred solution.

How do you think about to improve static source code analysis also for your software?

Do you find information sources like the following useful?

• Article "A Reusable Aspect for Memory Allocation Checking"
• Document "Aspect-Oriented Software Development - An Introduction" by Johan Brichau and Theo D'Hondt
• Paper "On Typesafe Aspect Implementations in C++" by Daniel Lohmann and Olaf Spinczyk

[droe]

I do not intend to introduce AoP to this project. I do welcome specific proposals to improve encapsulation, separation of concerns etc within the plain c codebase.

Regarding static analysis, have you seen the lint target of the current make file?

[elfring]

I guess that some more time will need to pass by until aspect-oriented development might become a general part also for your software design and maintenance.

The tool "cppcheck" can help to find some interesting issues in source code. But I find that it will not be useful to improve the situation for unused (or overlooked) return values at the moment.
I find other approaches more promising.

[droe]

By all means, feel free to run more promising approaches against the code base and submit the resulting patches.

[elfring]

How promising do you find tools like the following for suggested source code improvements?

• AspectC++
• Coccinelle

[droe]

Fixed bullet points 2 and 3. Not fixing bullet point 1 because if fprintf(stderr) fails at that point then there is no useful thing to do anyway.

[elfring]

Would you like to inform your program user by the exit status code that a requested file output failed eventually?

[droe]

I'm not opposed to accepting a patch for that if somebody cares about knowing if -V failed.

[elfring]

Would you like to look once more at any remaining update candidates?

• pthread_mutex_init ⇒ cert_new
• strdup ⇒ sys_user_str

[droe]

I will commit a fix for the first one, thanks. The second one is bogus; if strdup() fails, it returns NULL, which means sys_user_str() returns NULL, which in turn signals an error to the caller.

[elfring]

• Are there any more update candidates left over?
• How do you think about to care also for a failed string duplication?

[droe]

I am starting to wonder whether you are actually some kind of ELIZA specialized on suggesting code improvements. Can you submit at least a single valid pull request to prove that you are actually a human being capable of contributing code?

[elfring]

… some kind of ELIZA …

You can also notice (if you look around a bit more) that I contributed some concrete patches for various free software.
It can occasionally happen that this software will be fixed quicker by other contributors (than me).

Thanks for another small source code improvement.
Unfortunately, there are still more update candidates left over.

[droe]

thrqueue_enqueue() is a wont-fix, because those functions cannot fail under reasonable conditions. In my eyes, the cost/benefit ratio is not in favour of adding unneeded dead code and complexity there.

[elfring]

Do you like any reminders for the incomplete error detection (and corresponding exception handling) more from other contributors (or automatic source code analysis tools)?

[droe]

I'm afraid that I don't understand your question. I always welcome specific and thoughtful bug reports, regardless from whom.