Re: dropping setuid/setgid privileges

2009-06-08 Thread Sam Steingold
On Mon, Jun 8, 2009 at 8:19 PM, Bruno Haible wrote: > Sam Steingold wrote: > >> I urge you to avoid abort in favor of returning an error code and >> document that aborting on certain errors is the right behavior. > > If I did this, the risk that a bug does not get reported would be too down with

Re: dropping setuid/setgid privileges

2009-06-08 Thread Bruno Haible
Sam Steingold wrote: > While I understand your reasons for using abort() instead of returning > an error code, abort() is being used when the code has a bug. abort() causes a core dump, so that fellow developers can analyze and report the bug. > The generous usage of abort() in these modules make

Re: dropping setuid/setgid privileges

2009-06-08 Thread Sam Steingold
Bruno, The generous usage of abort() in these modules makes them unusable for CLISP. While I understand your reasons for using abort() instead of returning an error code, I do not think it is right for CLISP to die without a useful message. I urge you to avoid abort in favor of returning an error c

Re: dropping setuid/setgid privileges

2009-06-08 Thread Bruno Haible
And here's the module for temporarily dropping setuid/setgid privileges. (Dangerous!) 2009-06-08 Bruno Haible New module 'idpriv-droptemp'. * lib/idpriv-droptemp.c: New file. * modules/idpriv-droptemp: New file. = lib/idpriv-droptemp.c

Re: dropping setuid/setgid privileges

2009-06-08 Thread Bruno Haible
Thanks for the feedback. I'm committing the module as follows. 2009-06-08 Bruno Haible New module 'idpriv-drop'. * lib/idpriv.h: New file. * lib-idpriv-drop.c: New file. * m4/idpriv.m4: New file. * modules/idpriv-drop: New file. ===

Re: required memchr behavior

2009-06-08 Thread Bruno Haible
Eric Blake wrote: > Yes; I've done that as follows, and also added memchr as a dependency for > vasnprintf (the only module that used memchr but did not depend on it). Good, thanks. I do the same for the other modules that also use vasnprintf.c: 2009-06-08 Bruno Haible * modules/unis

Re: required memchr behavior

2009-06-08 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/31/2009 7:08 AM: >> But as there are systems in the wild with the broken implementation, we >> should probably start worrying about replacing the buggy memchr >> implementations. > > As a first step, let me add a test to

Re: [PATCH] hash: declare some functions with the warn_unused_result attribute

2009-06-08 Thread Jim Meyering
Eric Blake wrote: > According to Eric Blake on 6/7/2009 9:51 PM: >> According to Jim Meyering on 6/6/2009 2:41 PM: >>> A few of the function declarations in hash.h could benefit from >>> gcc's warn_unused_result attribute, so I'm adding it: >> >> Including one in hash.c itself: >> >> hash.c: In fu

Re: broken memchr

2009-06-08 Thread Simon Josefsson
Eric Blake writes: > According to Simon Josefsson on 5/26/2009 10:24 AM: >> My gnulib autobuilder is a x86_64 system (running Ubuntu 8.04 LTS), so >> if the test starts to fail, it will show up here in a few hours: >> >> http://autobuild.josefsson.org/gnulib/#000-gnulib-simple-gaggia > > The upd

Re: [PATCH] hash: declare some functions with the warn_unused_result attribute

2009-06-08 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 6/7/2009 9:51 PM: > According to Jim Meyering on 6/6/2009 2:41 PM: >> A few of the function declarations in hash.h could benefit from >> gcc's warn_unused_result attribute, so I'm adding it: > > Including one in hash.c itsel

Re: broken memchr

2009-06-08 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 5/26/2009 10:24 AM: > My gnulib autobuilder is a x86_64 system (running Ubuntu 8.04 LTS), so > if the test starts to fail, it will show up here in a few hours: > > http://autobuild.josefsson.org/gnulib/#000-gnulib-simpl