From: Hazen B. <hba...@ma...> - 2009-09-24 03:41:29
|
Hezekiah M. Carty wrote: > On Tue, May 5, 2009 at 4:05 AM, Andrew Ross > <and...@us...> wrote: >> On Mon, May 04, 2009 at 06:57:46PM -0700, Alan Irwin wrote: >>> On 2009-05-04 13:54-0600 Orion Poplawski wrote: >>>> Something else to think about? >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libplplotd.so.9.6.2 exit@GLIBC_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libqsastime.so.0.0.1 exit@GLIBC_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libcsirocsa.so.0.0.1 exit@GLIBC_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libcsironn.so.0.0.1 exit@GLIBC_2.2.5 >>>> >>>> >>>> $ rpmlint -I shared-lib-calls-exit >>>> shared-lib-calls-exit: >>>> This library package calls exit() or _exit(), probably in a non-fork() >>>> context. Doing so from a library is strongly discouraged - when a library >>>> function calls exit(), it prevents the calling program from handling the >>>> error, reporting it to the user, closing files properly, and cleaning up any >>>> state that the program has. It is preferred for the library to return an >>>> actual error code and let the calling program decide how to handle the >>>> situation. >>> I agree the "exit" issue is worth thinking about post 5.9.4. Otherwise, I >>> believe I have addressed all the issues you raised as of revision 9907. >>> Thanks for spotting all of those! >> Debian lintian also complains about this. (See >> http://lintian.debian.org/full/and...@us...ml ) >> >> I've looked at this briefly. There are several uses >> >> 1) plparseopts exits if there are invalid command line options or if the >> -h or -v options are used. This would be "normal" program behaviour, but >> we could change plparseopts to return an error code in these cases. It >> would then be up to the program to handle. Would be an API change. >> >> 2) plexit (used as default handler by plabort), and throughout the code. >> Removing plabort would be a significant API change. Removing all occurences >> of plexit would also be a significant amount of work since C doesn't support >> excepetions (unlike for example C++, java). >> >> 3) Other libraries: nn has a couple of calls to exit via nn_quit for error >> handling. Could probably be "fixed" with not too much work. qsastime makes >> quite a few calls to exit for error handling. Again, can be fixed but will >> be a little bit of work. Also calls in testing routines for nn, csa and >> qsastime. This is fine - just need to check code is not part of final >> library. Changes are likely to result in API changes since function return >> codes will alter. >> >> 4) Most drivers call exit or plexit somewhere in their code. Again, may be >> some work to "fix". >> >> This is an unfortunate practice we have got in to. It is now quite well >> entrenched in the plplot code so will take some work to unravel and will >> probably result in changes to return codes for a lot of API calls. This >> will require programs to do a lot more checking. >> >> Thoughts? > > It has been several months since this was brought up, but I think that > this is still worth addressing. Having the PLplot exit a program > completely can be a shock, particularly when using the library > interactively. I think that making these changes pre-5.10.0 would be > better than post-5.10.0. Otherwise I expect they would have to wait > for a 5.11.x development release due to the likelihood of an API > change. If you are using a language that supports exceptions and callbacks from C you can override the PLplot's default exit() behavior. Thoughts about how we would implement this? Would we have to change every function in API to return a success or failure code? This seems like a huge change, the kind of change that would take us from version 5 to version 6. -Hazen |