[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