On Mon, 2018-04-09 at 14:19 +0200, Petr Mladek wrote: > On Sat 2018-04-07 17:12:35, Andy Shevchenko wrote: > > On Fri, 2018-04-06 at 11:15 +0200, Petr Mladek wrote: > > > On Thu 2018-04-05 15:30:51, Rasmus Villemoes wrote: > > > > On 2018-04-04 10:58, Petr Mladek wrote:
> > > > > > > > > Please leave string() alone, except for moving the < PAGE_SIZE > > > > check > > > > to > > > > a new helper checked_string (feel free to find a better name), > > > > and > > > > use > > > > checked_string for handling %s and possibly the few other cases > > > > where > > > > we're passing a user-supplied pointer. That avoids cluttering > > > > the > > > > entire > > > > file with double-underscore calls, and e.g. in the %pO case, > > > > it's > > > > easier > > > > to understand why one uses two different *string() helpers if > > > > the > > > > name > > > > of one somehow conveys how it is different from the other. > > > > > > I understand your reasoning. I thought about exactly this as well. > > > My problem is that string() will then be unsafe. It might be > > > dangerous > > > when porting patches. > > > > I agree with Rasmus, and your argument here from my point of view > > kinda > > weak. Are we really going to backport this patches? Why? We lived > > w/o > > them for a long time. What's changed now? > > Someone might have out-of-tree patch that adds yet another format > specifier. It might call string() that checks for (null) now but > it it won't if we rename it as you suggest. People used to safe > string() might miss this when the patch is send upstream for > inclusion, ... This is even weaker argument. Sorry, but I don't care about out-of-tree core patches. If they have them, they are doing completely wrong, or the patches are crappy. -- Andy Shevchenko <andriy.shevche...@linux.intel.com> Intel Finland Oy