Continuing, sort of, beyond the comment on small points, 4. NOT A SMALL POINT. Peter's observation about private allocators and reference counting reminds me that we could also be using the Microsoft COM binary interface, with its scheme for reference counting), but using our own interface factories. This is also a good way to pass an interface to quick-check code so that the caller can provide an error handler, except for the fact that COM interfaces are not allowed to produce exceptions. This doesn't get the stack walkback that I think Peter is talking about. That takes a different kind of magic. It does handle the correct release of shared in-memory data structures.
There are fully-portable definitions of COM interfaces that work on any C/C++ compiler model (that allow pointers to functions in structs), although it is nicer when the code is compiled as C++ even though the bindings are all for C. It is not necessary to go the IDL and MIDL compiler route for strictly in-process local usages in native code, and there is no need for the COM system manager or any other run-time additions. 5. (4) is not a small point. I just wanted to point out that there is a well-defined reference-counting interface scheme that is widely used, although often under the cover of C++ class definitions. This is very interesting, though, for dynamic integration of different filters and for filters to be able to communicate with their hosts as is demonstrated with the Java JNI technique (one that I have applied in practice). I have not done the work to see how well something like that slides under the AOO UNO scheme, but it appears to have the same reference-count handling but with different method names. This would be a much longer, but perhaps extremely profitable line of investigation. I am committed to exploring this avenue whether on behalf of Corinthia or Apache OpenOffice or none of the above. My work on building document-processing tools from the Zip (i.e., the ISO DCF format, OPC, ODF Package) on up will follow this course. - Dennis PS: To the horror of some, it is discovered that COM is back as a fundamental kind of dynamic glue in the Windows runtime. (I say some ideas are just too good to stay dead.) Although it figures in conjunction with what was called the WinRT API, it is pretty invisible in .NET languages, where COM use is near invisible. What interests me is how this works into the asynchronous coordination model of WinRT and therefore Windows Universal apps. I have no idea at this point. -----Original Message----- From: Peter Kelly [mailto:[email protected]] Sent: Thursday, February 19, 2015 04:51 To: [email protected] Subject: Re: Checking malloc success and adding perror() > On 19 Feb 2015, at 6:15 pm, jan i <[email protected]> wrote: > > On 19 February 2015 at 05:05, Peter Kelly <[email protected]> wrote: > >> The next thing to address i cleanup. If a malloc failure occurs deep in a >> conversion run, and we jump out to an exception handler, we should free all >> memory that was allocated during that run. This means wrapping >> malloc/calloc/realloc/strdup and any other functions in the C library, and >> using our own data structure to keep track of what has been allocated (and >> also to update this data structure when memory is freed). Then, if an error >> occurs, after we return to the call site of setjmp() and go into the >> exception handling block, we go through this data structure and call free() >> on all the blocks of memory that were allocated by DocFormats, so the >> application can then show an error message and then continue operating. >> > Now this is quite a different discussion.....do we want to recover > gracefully from severe errors or simply make sure the whole application > terminates. > > I advocate that we cannot recover gracefully from all severe errors, so no > reason breaking our backs trying. I think it’s worth a try. The exception handling approach along the lines of what I mentioned I did with TeX would work. If we ensure all allocations go through our wrapper functions, then we can ensure that memory is freed when we do have a problem, and then return an appropriate error code to the application. Of course that doesn’t address logic errors in the code, which can still cause crashes, but would nicely handle the case of out-of-memory problems. The wrapper functions will also make testing of this much easier; we can have a test driver option that causes allocation to fail after a randomly-chosen number of calls, and repeat a conversion with the same input many times but different failure injection points. — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
