From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Jones Subject: Re: [PATCH] fs: replace int param with size_t for seq_open_private() Date: Fri, 12 Sep 2014 15:43:33 +0100 Message-ID: <54130695.1080707@codethink.co.uk> References: <1409577428-16148-1-git-send-email-rob.jones@codethink.co.uk> <20140901153637.GI7996@ZenIV.linux.org.uk> <5411CD05.6050705@codethink.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Al Viro , LKML , linux-fsdevel , Andrew Morton , linux-kernel@codethink.co.uk To: Richard Weinberger Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 12/09/14 15:16, Richard Weinberger wrote: > On Thu, Sep 11, 2014 at 6:25 PM, Rob Jones wrote: >> >> >> On 01/09/14 16:36, Al Viro wrote: >>> >>> On Mon, Sep 01, 2014 at 02:17:08PM +0100, Rob Jones wrote: >>> >>>> void *__seq_open_private(struct file *f, const struct seq_operations >>>> *ops, >>>> - int psize) >>>> + size_t psize) >>> >>> >>> >>> It is a horrible limitation to impose, indeed. Why, a lousy >>> 2 gigabytes per line in procfs file - that's intolerable... >>> >>> >>> >> >> OK, I know this is a trivial patch but I've gone away and thought about >> it and done some reading to see what the rest of the world thinks about >> using size_t vs unsigned int (signed int is an abomination in this >> context regardless). >> >> I think Al's sarcasm is misplaced. >> >> The correct type to use here *is* size_t. It's about consistency and, >> more importantly, it's about not making assumptions about the hardware >> architecture. It's included in the language for very good reasons and >> it seems to me to be risky to ignore those reasons. > > Please don't forget to patch all for loops to use size_t instead of int too. > Yes, I'm sure we've all read that argument too. Now try behaving like a grown up. -- Rob Jones Codethink Ltd mailto:rob.jones@codethink.co.uk tel:+44 161 236 5575