2009/11/10 Dag-Erling Smørgrav :
> Alexander Best writes:
>> you're right. hundreds of functions cause segfaults when arg or args
>> are NULL. either we add safety checks for all of them (massive
>> overhead) or just leave them the way they are.
>
> The consensus in the C community is that adding
Alexander Best writes:
> you're right. hundreds of functions cause segfaults when arg or args
> are NULL. either we add safety checks for all of them (massive
> overhead) or just leave them the way they are.
The consensus in the C community is that adding such checks does more
harm than good, be
> On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote:
> > On Tue, 10 Nov 2009, Alexander Best wrote:
> >
> > >ps: would be nice if strcasecmp could protect itself from segfault
> > >with one or both of the args being NULL.
> >
> > I disagree. What do you think it should do instead? Ret
On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote:
> On Tue, 10 Nov 2009, Alexander Best wrote:
>
> >ps: would be nice if strcasecmp could protect itself from segfault with
> >one or
> >both of the args being NULL.
>
> I disagree. What do you think it should do instead? Return 0?
Nate Eldredge schrieb am 2009-11-10:
> On Tue, 10 Nov 2009, Alexander Best wrote:
> >ps: would be nice if strcasecmp could protect itself from segfault
> >with one or
> >both of the args being NULL.
> I disagree. What do you think it should do instead? Return 0? If
> it did, would you have fou
On Tue, 10 Nov 2009, Alexander Best wrote:
ps: would be nice if strcasecmp could protect itself from segfault with one or
both of the args being NULL.
I disagree. What do you think it should do instead? Return 0? If it
did, would you have found your bug?
The same argument could be made f
Dag-Erling Smørgrav schrieb am 2009-11-10:
> Alexander Best writes:
> > good point. is this one better?
> Yes (modulo indentation - run your code through tabify)
> DES
oops. found another problem. if BURNCD_SPEED and -s aren't defined strcasecmp
segfaults because env_speed is NULL.
does this p
Alexander Best writes:
> good point. is this one better?
Yes (modulo indentation - run your code through tabify)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ha
Dag-Erling Smørgrav schrieb am 2009-11-09:
> Alexander Best writes:
> > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
> > + if (strcasecmp("max", env_speed) == 0)
> > + speed = CDR_MAX_SPEED;
> > + else
> > + speed = atoi
Alexander Best writes:
>
> + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
> + if (strcasecmp("max", env_speed) == 0)
> + speed = CDR_MAX_SPEED;
> + else
> + speed = atoi(env_speed) * 177;
> + if (speed <= 0)
>
here's the final patch. would be great if somebody could commit this one. the
only thing i'm not 100% sure about are the burncd(8) changes. i'm not that
familiar with the man syntax.
thanks go out to keramida@ and des@ for their help.
alex
...just realised the topic makes no sense. ;) what i mea
Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best
> wrote:
> >Giorgos Keramidas schrieb am 2009-11-09:
> >> > 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 -
On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best
wrote:
>Giorgos Keramidas schrieb am 2009-11-09:
>> > 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 perfor
Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best
> wrote:
> > Giorgos Keramidas schrieb am 2009-11-09:
> >> Hi Alexander,
> >> The idea seems very good, but since the value of SPEED is user
> >> supplied data, I would rather see a bit of validati
On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best
wrote:
> Giorgos Keramidas schrieb am 2009-11-09:
>> 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 th
Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best
> wrote:
> > any thoughts on these small changes to burncd?
> > Index: usr.sbin/burncd/burncd.c
> > ===
> > --- usr.sbin/burncd/burnc
Giorgos Keramidas writes:
> Dag-Erling Smørgrav wrote:
> > man 3 expand_number
> I know, but thanks. In this case, expand_number's logic for parsing
> possible SI suffixes is not useful and may be slightly confusing.
>
> I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option,
> for
On Mon, 09 Nov 2009 11:00:43 +0100, Dag-Erling Smørgrav wrote:
> Giorgos Keramidas writes:
>> atoi() doesn't really have error checking and it does not necessarily
>> affect `errno'.
>
> man 3 expand_number
I know, but thanks. In this case, expand_number's logic for parsing
possible SI suffixes
Giorgos Keramidas writes:
> atoi() doesn't really have error checking and it does not necessarily
> affect `errno'.
man 3 expand_number
And please don't call it SPEED or WRITE_SPEED or anything generic; call
it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar
used to specify
On Mon, 09 Nov 2009 02:22:36 +0100 (CET), Alexander Best
wrote:
> --- burncd.c.typo 2009-11-09 02:19:47.0 +0100
> +++ burncd.c 2009-11-09 02:20:27.0 +0100
> @@ -85,8 +85,8 @@
> if ((dev = getenv("CDROM")) == NULL)
> dev = "/dev/acd0";
>
> - if ((env_sp
On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best
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
Gabor Kovesdan schrieb am 2009-11-09:
> Gabor Kovesdan escribió:
> >Alexander Best escribió:
> >>any thoughts on these small changes to burncd?
> >> -int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> >>+int nogap = 0, speed = 0, test_write = 0, force = 0;
> >>int block_size =
Gabor Kovesdan schrieb am 2009-11-09:
> Gabor Kovesdan escribió:
> >Alexander Best escribió:
> >>any thoughts on these small changes to burncd?
> >> -int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> >>+int nogap = 0, speed = 0, test_write = 0, force = 0;
> >>int block_size =
Gabor Kovesdan escribió:
Alexander Best escribió:
any thoughts on these small changes to burncd?
-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
Alexander Best escribió:
any thoughts on these small changes to burncd?
- 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
25 matches
Mail list logo
