Øyvind Harboe wrote: > Thank you for a *much* better analysis of the problem. > > (I checked a few sites and you missed a case where cfi.c is broken > if you remove the warning, i.e. no error/warning is logged if you > run out of working area, but otherwise a very productive post) > > >> I'm still convinced that the warning in target_alloc_working_area() >> is misplaced. With the current situation, a bunch of warning may >> be issued, but the software runs perfectly. >> > > I suggest that you create a new fn target_alloc_working_area_no_error() > and invoke that for the "try" code and use LOG_ERROR() in > target_alloc_working_area() . > > You can then delete all the superfluous LOG_ERROR() statements in > code today that invokes target_alloc_working_area(). > > Like exceptions, the calling code can either pass up the exception, > default case or catch(here the _no_error() is our equivalent) and > handle the error. > > Like exceptions it's possible to catch an exception and ammend > context information if necessary, most of the time just passing up > an "out of working space" will be more than sufficient. > > (don't mention malloc() in this context, because we have swept > all that error handling under the carpet for small allocations, here > C++ exceptions would have made the code robust...) > > My head spins, do you really propose that we should have to functions doing exactly the same functionality, the only difference being how a failure is LOGGED ?????????????????
How about the discussion about tetstable code paths. I know you have opinions about the error handling and I can partly agree. But this is not the way to fix it. If the cfi.c does not recognise an error return from the allocation then it is BROKEN with or without reporting the failure as an error event or a debug log event. This is a problem, but the original patch proposal is still correct. If Rolf like to fix the problems in the calling code then that is very velcome, but do we really require every patch subission that fixes a problem to also fix all problems in calling code ? We have not swept all error handling under the carpet. The case we are discussing is really reporting the failure. And my argument, and as far as I can understand, Rolfs also, is that the calling code should handle this reported problem. There is no no need for try/catch mechanisms, just "read and respect the return code" ! Best regards Magnus _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
