[patch] various bugs and strncpy abuse followup

Rob Landley rob at landley.net
Wed Jun 7 20:31:16 UTC 2006


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"?

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list