[patch] various bugs and strncpy abuse followup

Erik Hovland erik at hovland.org
Wed Jun 7 21:12:42 UTC 2006


On Wed, Jun 07, 2006 at 04:31:16PM -0400, Rob Landley wrote:
> On Wednesday 07 June 2006 3:09 am, Tito wrote:
> > Hi, in the vlock patch:
> >
> > I can't say due to my limited knowledge if it makes sense
> > to have error messages in signal handlers, but nonetheless
> > they could be shorter. ;-)
> >
> >  static void release_vt(int signo)
> >  {
> > -	if (!o_lock_all)
> > -		ioctl(vfd, VT_RELDISP, 1);
> > -	else
> > -		ioctl(vfd, VT_RELDISP, 0);
> > +	if (!o_lock_all) {
> > +		if (ioctl(vfd, VT_RELDISP, 1) < 0)
> > +			bb_error_msg("failed in attempting to release the display");
> > +	} else
> > +		if (ioctl(vfd, VT_RELDISP, 0) < 0)
> > +			bb_error_msg("failed in attempting to release the display");
> >  }
> 
> It's not Busybox's policy to test if you encountered bad ram during the course 
> of operation.  Will the user not otherwise notice this failure if the console 
> doesn't unlock?  What exactly are they supposed to do about it if it happens?  
> Is it at all likely to happen in the regular course of operations?  (What 
> would cause this to happen?  The ioctl returns an error primarily because the 
> console might not have been locked in the first place, not because the kernel 
> can't be trusted to do its job reliably...)
> 
> Could ignoring this error conceivably be any worse than reporting it?  It's 
> not like the program is going to DO anything about it, the error message is 
> just the program is sticking its tongue out at the user.
> 
> There are lots of errors we don't test for because we ignoring it is no worse 
> than reporting it.  If we can't do anything useful about it and it's not 
> going to eat your data, is it worth the bytes being pedantic over a "this 
> should never happen"?

This is just the sort of discussion that I was hoping to have by
throwing these patches out there. In my day job we find that being
pedantic is always the right choice. We want to know that things are
going bad as soon as possible.

Having read your and Tito's comments, I am definitely of a mind to back
out this change at least. Reporting it only belabors reporting a known
bad state.

Thanks again for the comments.

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request



More information about the busybox mailing list