From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06723343D91 for ; Wed, 3 Jun 2026 13:53:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780494839; cv=none; b=p+Y6tIUeZvlMqNZ/bH7coofYha85WpsPX8ozQ2tG6vmaTOHxcBHIBwlN3cAO9h27+nV8jFPUYufAu9BJb+L71cxCntxQy1tZ772qJdrY3BtxstsW65DoSz52rFFZrMMM0RWTNAle7Y4MGDpS04ppn3pM95j7qQBxkZwZgUhDoEk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780494839; c=relaxed/simple; bh=L9zblBebZ3aetDt5RUk8Id1dS0PPQJ/tWuoKzF0K+8U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PEVDavm3Tx0h211Sm6KiZZPeYlzdl3rQ8k8+8S9uS2InnxM9mSAlYtZbr0oCWb7htbcW6tRNOym4AZqrLl8l9urfdxxTZiSzQWcSEuCh9+025cEZ8tSWa1xOLudNxRJOkF3zL1zhhRsJQiVSa8TVlgs/lRW2axOMAO1aDjb4nvI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Fmjo6gTX; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Fmjo6gTX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780494836; x=1812030836; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=L9zblBebZ3aetDt5RUk8Id1dS0PPQJ/tWuoKzF0K+8U=; b=Fmjo6gTXN9PkjsBj2x7M3KtR+GZslyZk8P3v4bY0+2PERXuTx8EfaQzM YbMXmksKPN8Lz//NWPAW0+aeQRf3kXTeZsq9EbUEzEzomFHPge+Pq+tsI a32+ecW0p0xthEc1nSXDeS+QFk1B+L/+pPX9nzXVls+VfFBBV9y5XMaCW RrFDLECHnn7LdEOgkJPRzDMoz3o2wOCagKD/buIDkbFfU/QlFJY4SKRyi Cny6EBQ1gq1j7Of8100fb0eziin1/xUs5iJfEgkjeoXYxBsssMHE2tvn9 bUVuBtkBBlKvchn1SwRQIaUzCoD094ZBjgBjADBdstHLWmCtGlbvuMHCM w==; X-CSE-ConnectionGUID: j/LjlDkgThSarYLaOjnHfA== X-CSE-MsgGUID: 8bONWw5zRzeEqCTWU/Dtnw== X-IronPort-AV: E=McAfee;i="6800,10657,11805"; a="84928358" X-IronPort-AV: E=Sophos;i="6.24,185,1774335600"; d="scan'208";a="84928358" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2026 06:53:55 -0700 X-CSE-ConnectionGUID: PKqrkeW4TEutREJLXKcUow== X-CSE-MsgGUID: 0PJw47nYTvyLlEBT47DVWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,185,1774335600"; d="scan'208";a="248193775" Received: from slindbla-desk.ger.corp.intel.com (HELO localhost) ([10.245.244.250]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2026 06:53:52 -0700 Date: Wed, 3 Jun 2026 16:53:49 +0300 From: Andy Shevchenko To: Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Cc: Petr Mladek , Dmitry Antipov , linux-kernel@vger.kernel.org, Andrew Morton , Steven Rostedt , Rasmus Villemoes , Sergey Senozhatsky , rodrigo.alencar@analog.com, dlechner@baylibre.com, jic23@kernel.org Subject: Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible Message-ID: References: <20260602203706.103449-1-andriy.shevchenko@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Wed, Jun 03, 2026 at 12:51:09PM +0100, Rodrigo Alencar wrote: > On 26/06/03 01:23PM, Petr Mladek wrote: > > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote: > > > Currently every new wrapper on _parse_integer_limit() will need a new name > > > to share with users while keeping some optional arguments to be initialised > > > explicitly. Since there is an attempt to expand this more, I decided to > > > suggest this mini series to avoid namespace pollution and unneeded churn in > > > the future. > > > > > > To expand this API more, the possible future change may be: > > > > > > unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res, > > > - size_t max_chars); > > > + size_t max_chars, $new_opt_arg); > > > > > > #define _parse_integer0(s, base, res, ...) \ > > > - _parse_integer_limit(s, base, res, INT_MAX); > > > + _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default); > > > > > > #define _parse_integer1(s, base, res, max_chars, ...) \ > > > - _parse_integer_limit(s, base, res, max_chars); > > > + _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default); > > > > > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...) \ > > > + _parse_integer_limit(s, base, res, max_chars, new_opt_arg); > > > > I guess that this is about _parse_integer_limit_init() from > > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@analog.com/ > > > > I personally find > > > > _parse_integer(*s, base. *res) > > _parse_integer_limit(*s, base, *res, max_chars) > > _parse_integer_limit_init(*s, base, init, *res, max_chars) > > What could also be done is having a _parse_integer_ext() that would > contain all the necessary arguments (one that should be indicated > not to be used) and define all the other variations as static inline > functions. I suppose that combines both ideas, being a pattern that > is also used elsewhere: > > devm_regulator_get() > devm_regulator_get_enable() > devm_regulator_get_enable_optional() devm_regulator_get*() are public APIs and that split might make sense. The _parse_integer() is internal to printf() implementation and wrappers around it, so I don't think we should really be so picky. TL;DR: I think my approach is good enough and makes not much of turbulence here, perhaps a comment would be nice to have to explain the list of optional arguments. > > a bit more self-explanatory than > > > > _parse_integer(*s, base. *res) > > _parse_integer(*s, base, *res, max_chars) > > _parse_integer(*s, base, *res, max_chars, init) > > > > especially when the meaning of the arguments need not be obvious > > when the function is used in the code. > > > > Also the macro magic increases the complexity of the code. > > > > On the other hand, I do not have strong opinion. It is not a big deal. > > I am not going to block it. Would you give your tag in case Rodrigo wants to incorporate these into his series and go via IIO tree? (I think that these two makes sense to put into immutable branch/tag and share with the users). > > > So you got the idea. (It is roughly overloaded function in OOP.) -- With Best Regards, Andy Shevchenko