From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiLWS-0001Od-Gg for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:58:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiLWN-0001G2-R4 for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:58:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiLWN-0001Fx-KA for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:58:03 -0400 Date: Sun, 26 Oct 2014 10:57:59 +0000 From: "Richard W.M. Jones" Message-ID: <20141026105759.GU15695@redhat.com> References: <1414312958-21967-1-git-send-email-rjones@redhat.com> <1414312958-21967-2-git-send-email-rjones@redhat.com> <544CB78A.3090403@huawei.com> <20141026102248.GS15695@redhat.com> <544CD0AE.7040802@huawei.com> <20141026104808.GT15695@redhat.com> <544CD319.40601@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544CD319.40601@huawei.com> Subject: Re: [Qemu-devel] [PATCH v1 repost 2] block/curl: Improve type safety of s->timeout. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gonglei Cc: "kwolf@redhat.com" , "lersek@redhat.com" , "qemu-devel@nongnu.org" , "stefanha@redhat.com" On Sun, Oct 26, 2014 at 06:55:21PM +0800, Gonglei wrote: > On 2014/10/26 18:48, Richard W.M. Jones wrote: > > > On Sun, Oct 26, 2014 at 06:45:02PM +0800, Gonglei wrote: > >> On 2014/10/26 18:22, Richard W.M. Jones wrote: > >> > >>> It's just there to stop unreasonable timeouts or negative numbers. > >>> 100000 s is 27 hours, and no webserver I know of would keep a > >>> connection open that long. Possibly not even the IP stack. > >>> > >> > >> Yes, it is. But 26 hours is OK? I just think we should assure the timeout > >> as reasonable range, absolutely 100000 is too big IMO. > >> > >>> What's the difference between defining a number at the top of the file > >>> to be used once, and placing it exactly where it is used? Except the > >>> former introduces long range dependencies into the code making it > >>> harder to read and more fragile when changed. > >> > >> > >> That's the purpose using macro. If this value is used only one place in the > >> curl.c (or other c files) now and future, you are fine with it. :) > > > > I don't understand this part. Can you explain how you think a macro > > should be used? > > > > Sorry for misapprehension. I mean that's the purpose using macro what your said: > " Except the former introduces long range dependencies into the code making it > harder to read and more fragile when changed." OK, so our coding style is about introducing fragility and long range dependencies. v2 coming up ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v