[patch] burncd: honour for envar SPEED
Alexander Best
alexbestms at math.uni-muenster.de
Mon Nov 9 14:39:17 UTC 2009
Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best
> <alexbestms at math.uni-muenster.de> wrote:
> > any thoughts on these small changes to burncd?
> > Index: usr.sbin/burncd/burncd.c
> > ===================================================================
> > --- usr.sbin/burncd/burncd.c (revision 199064)
> > +++ usr.sbin/burncd/burncd.c (working copy)
> > @@ -78,13 +78,16 @@
> > {
> > int arg, addr, ch, fd;
> > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0,
> > preemp = 0;
> > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> > + int nogap = 0, speed = 0, test_write = 0, force = 0;
> > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> > const char *dev;
> > if ((dev = getenv("CDROM")) == NULL)
> > dev = "/dev/acd0";
> > + if ((speed = getenv("SPEED")) == NULL)
> > + speed = 4 * 177;
> > +
> > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> > switch (ch) {
> > case 'd':
> Hi Alexander,
> The idea seems very good, but since the value of SPEED is user
> supplied
> data, I would rather see a bit of validation code after getenv().
> With
> this version of the patch, burncd would happily accept and try to use
> values that are quite absurd, i.e.:
> env SPEED=12234567890 burncd ...
> It may also be sensible to do the translation from "human readable"
> speed values and the multiplication with 177 _after_ the value has
> been
> parsed from getenv(), so that e.g. one can write:
> env SPEED=4 burncd
> and get behavior similar to the current default.
i don't quite get why the value supplied with the envar has to be validated.
if the user supplies a speed value using the -s switch no validation (except
<= 0) is being performed either.
also i think there's a speed check in the atapi code. if the speed requested
is > the maximum driver speed it gets set to the maximum driver speed
automatically.
cheers.
alex
More information about the freebsd-hackers
mailing list