From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiLUD-0000MH-18 for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:55:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiLU6-0000Y6-U2 for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:55:48 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:30370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiLU6-0000Y1-6r for qemu-devel@nongnu.org; Sun, 26 Oct 2014 06:55:42 -0400 Message-ID: <544CD319.40601@huawei.com> Date: Sun, 26 Oct 2014 18:55:21 +0800 From: Gonglei MIME-Version: 1.0 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> In-Reply-To: <20141026104808.GT15695@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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: "Richard W.M. Jones" Cc: "kwolf@redhat.com" , "lersek@redhat.com" , "qemu-devel@nongnu.org" , "stefanha@redhat.com" 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." Best regards, -Gonglei