What steps will reproduce the problem?
No reproducible issue, just looking into cleaning up the codebase a little.
Please use labels and text to provide additional information.
Provided are two patches. Their main features are as follows:
1. memry removal.
This should be no-brainer. These functions never seemed to do anything useful.
The only oddity was with alloc_string which rounded the allocation upwards to
nearest multiple of 4. Based on my review of code, I could not identify any
value in this feature, so even alloc_string was simply transformed to malloc.
memry.* are removed. All code is adjusted to simply call malloc and free
instead.
listio.* are removed. The list reading function in these files appears to have
been unused, and contained the only invocation of strsave define, which was one
of the alloc_string users, so I removed both of them.
2. memry and emalloc removal.
As above, but also removes emalloc* and replaces all uses of
E{malloc,realloc,free} with the standard versions.
This is somewhat more controversial, because the E variants bothered to check
the return value from the respective function, and would perform DoError if it
determined it to have failed, which terminates in message to console and
err_exit(). This is arguably nicer than crashing on null pointer value, but
large parts of the code have never cared about malloc's potential NULL values,
so I'd say it doesn't really help that parts of it now do.
Perhaps the real plan for moving forwards is to also replace malloc/free, and
instead start using new/delete operators, and allow them to throw exceptions if
the object construction fails due to memory allocation error. In this sense,
the second patch may be considered as a stepping stone on the path towards such
future version of Tesseract.
Original issue reported on code.google.com by alank...@bel.fi on 13 May 2014 at 8:48
Original issue reported on code.google.com by
alank...@bel.fion 13 May 2014 at 8:48Attachments: