Date: Wed, 8 Sep 2010 13:43:50 +0000 From: Alexander Best <arundel@freebsd.org> To: Dag-Erling =?iso-8859-15?Q?Sm=F8rgrav?= <des@des.no> Cc: freebsd-hackers@freebsd.org Subject: Re: expand_number() for fetch'es -B and -S switches Message-ID: <20100908134350.GA34547@freebsd.org> In-Reply-To: <8662ygihge.fsf@ds4.des.no> References: <20100901222834.GA66517@freebsd.org> <864oe8mpga.fsf@ds4.des.no> <20100902114655.GA9071@freebsd.org> <8639tsl5q0.fsf@ds4.des.no> <20100902122348.GA38047@freebsd.org> <86pqwwjoef.fsf@ds4.des.no> <20100905203757.GA11586@freebsd.org> <86r5h4shbu.fsf@ds4.des.no> <20100908105050.GA4892@freebsd.org> <8662ygihge.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed Sep 8 10, Dag-Erling Smørgrav wrote: > Alexander Best <arundel@freebsd.org> writes: > > Dag-Erling Smørgrav <des@des.no> writes: > > > Alexander Best <arundel@freebsd.org> writes: > > > > so how about forgetting about expand_number() and simply > > > > introducing a maximum buffer size of 1 megabyte? > > > so how about just leaving the code alone? :) > > i thought you wanted to have a maximum buffer size of 1MB in fetch? > > Yes, I was just commenting on the highly roundabout way we followed only > to end up almost at the status quo. > > > right now -B can be any value and it's quite easy to trigger ENOMEM. > > "don't do that, then!" > > My suggestion is that if you're going to change it at all, use > expand_number() *and* limit it to 1 MB. hmmm...i guess it's best to leave it as it is now, because: 1) it's not really worth adding expand_number(), if the limit is 1m. the difference between typing '-B 1m' and '-B 1048576' is rather minor. 2) adding a fetch(1) entry, telling the user that in fact he can use '-B 1g', but this get's silently reduced to 1m would make things more complicated. since, as you pointed out, using a buffer > 1m isn't going to improve anything, there's no point in making it easier for the user to use higher values than this (i.e. by introducing expand_number()). sorry for all the hassle. ;) ps: you might still want to consider adding the attached patch, which makes it more apparent that the -S switch causes problems. `fetch -B 10000 -S 145l86` e.g. will output: "fetch: invalid size (145l86)", however the user might not now which of the switches caused 'fetch' to fail. cheers. alex > > DES > -- > Dag-Erling Smørgrav - des@des.no -- a13x --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fetch.diff" diff --git a/usr.bin/fetch/fetch.c b/usr.bin/fetch/fetch.c index 7553bd8..852e948 100644 --- a/usr.bin/fetch/fetch.c +++ b/usr.bin/fetch/fetch.c @@ -842,7 +842,7 @@ main(int argc, char *argv[]) case 'S': S_size = (off_t)strtol(optarg, &end, 10); if (*optarg == '\0' || *end != '\0') - errx(1, "invalid size (%s)", optarg); + errx(1, "invalid file size (%s)", optarg); break; case 's': s_flag = 1; --k+w/mQv8wyuph6w0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100908134350.GA34547>