Completion of error handling

[elfring]

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

• fseek ⇒ InputBuffer constructor
• malloc ⇒ SquishedDawg::build_node_map
• pthread_mutex_init ⇒ CCUtilMutex constructor

[zdenop]

Feel free to send PR...

[elfring]

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

[zdenop]

As you can see on README we use https://lgtm.com and coverity.com for code analysis.

[elfring]

Do these analysis tools point also the open issues out which I reported?

[stweil]

Coverity Scan reports some of those errors – unless they are already fixed. :-)
LGTM does not report the mentioned errors.

• fseek ⇒ InputBuffer constructor, still buggy, not reported
• malloc ⇒ SquishedDawg::build_node_map, was fixed some time ago
• pthread_mutex_init ⇒ CCUtilMutex constructor, still buggy, not reported

Which static code analyser would you suggest to detect such errors?

[elfring]

I suggest to avoid ignorance of return values a bit more.
Would you like to detect every error situation as early as possible?

---

• Are you interested to apply aspect-oriented software development?
• Would you like to encapsulate error detection and corresponding exception handling as a reusable aspect in this software?

[stweil]

Sure, but my question was more specific. There is currently a lot of code which does not follow those principles, and more such code could get merged. Without a lot of man power, it is impossible to detect all missing checks of return values. So it is important to have tools which report violations. Do you know such tools?

[stweil]

As there are still some of the mentioned errors not fixed, I reopen this issue.

[elfring]

I know a few higher level development tools which can help here.
Which ones would you dare to integrate into the software build process?

[stweil]

Just tell us the names of those tools, then we can decide.

[elfring]

Examples:

• AspectC++
• Coccinelle
• Cppcheck

[stweil]

Thank you. I know and used the last two. Coccinelle itself does not find problems – it needs scripts written to do this. Cppcheck did not report missing handling of return values last time when I used it (well, that was some years ago).

[elfring]

Coccinelle itself does not find problems

This software tool can also find and adjust various questionable source code. It supports the C programming language better than C++ so far.

(well, that was some years ago)

I suggest to try Cppcheck out again to see if this analysis tool was improved in desired ways in the meantime.

---

Would you like to get help from any additional development tools?

[zdenop]

@elfring : Will you provide output of your code analyze?
Maybe as new issue (grouped by type) so we can close it with commit? Patches are welcomed too ;-)

[elfring]

Will the mentioned tools become relevant for your software development process?

[zdenop]

@elfring : I am sorry, but I did not get point of your question. Primary build system are autotools. Of course I am interested also in support cmake ...

[elfring]

Did your interest increase for the application of the tool “AspectC++” (together with related information sources for example)?

[zdenop]

What does it mean practically?
There is basically not intention to extend dependency to another libraries.
Also the main development is done in google, so unless the some approaches are accepted by Ray, it does not make sense to implement it by community...

[stweil]

@elfring, I don't think that Tesseract will switch from C++ to Aspect C++ as that is currently not a common standard. As far as I could see Aspect C++ cannot be used to check the existing code. Nor can Coccinelle because it only supports C but not C++. So only cppcheck remains which can be used in addition to Coverity Scan and LGTM.

The problems with malloc will be addressed by replacing that code with modern C++ data types. See also the planning page in the wiki.

If you have fixes for ignored return values, they are welcome.

[elfring]

As far as I could see Aspect C++ cannot be used to check the existing code.

I suggest to take another look at the provided technology.
Which systematic development methods do you know for the handling of cross-cutting concerns?

Nor can Coccinelle because it only supports C but not C++.

This tool can be useful for limited source code analysis and corresponding transformations.
Would you like to help in any ways to improve the support for the C++ programming language here?

If you have fixes for ignored return values, …

I would prefer the application of available known methodologies.

[zdenop]

@elfring: any help with improving code is welcomed. Pointing to new tools/methodology is interesting but... we have limited sources and most of active contributors will probably still continue to use what they are familiar.
So if there is problem with code, you can fix, please create new issue/send PR.

[elfring]

It is probably obvious that I am trying for a while to get more software developers familiar also with other helpful methodologies.
🔮 I am curious if their popularity will grow.