Hezekiah M. Carty wrote: > On Tue, May 5, 2009 at 4:05 AM, Andrew Ross > <andrewr...@users.sourceforge.net> 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 e...@glibc_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libqsastime.so.0.0.1 e...@glibc_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libcsirocsa.so.0.0.1 e...@glibc_2.2.5 >>>> >>>> plplot-libs.x86_64: W: shared-lib-calls-exit >>>> /usr/lib64/libcsironn.so.0.0.1 e...@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/andrewr...@users.sourceforge.net.html ) >> >> 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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
