From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752854AbbIPMx7 (ORCPT ); Wed, 16 Sep 2015 08:53:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41070 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752580AbbIPMx6 (ORCPT ); Wed, 16 Sep 2015 08:53:58 -0400 Subject: Re: [RFC PATCH 0/3] fix *pbl format support To: Rasmus Villemoes References: <1442394523-19176-1-git-send-email-mlombard@redhat.com> <87d1xi4kic.fsf@rasmusvillemoes.dk> Cc: tj@kernel.org, joe@perches.com, linux-kernel@vger.kernel.org From: Maurizio Lombardi Message-ID: <55F96664.8040701@redhat.com> Date: Wed, 16 Sep 2015 14:53:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <87d1xi4kic.fsf@rasmusvillemoes.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 09/16/2015 02:27 PM, Rasmus Villemoes wrote: > > If we want to fix the problem with 3/3, then this seems obviously > necessary. There may be stuff we want to optimize later (for example, I > don't think we should always make a local copy of the entire struct; Yes I know, I just tried not to break anything in the process, optimizations can be done later. > I haven't looked carefully at your code, but it does seem that you make > sure that at least the return value is as expected, which will make > kasprintf work. But it seems there is another kasprintf > problem. [reminder: kasprintf works by doing a va_copy, then doing a > first call of vsnprintf, passing NULL for the buffer and 0 for the > length to determine the size to allocate, and then doing the actual > formatting with a second call] Ah, you're right, PATCH 2 is broken because I didn't think to the case you described. Please ignore it, thanks for catching this. > I'm not yet completely convinced this is the right solution. Obviously, > if other problems with the small .field_width size show up, this might > be necessary, but as long as it's only the %pb formatter (and so far > only a single user of that), I think smaller/other hammers should be > thought about. So far I think there've been two alternatives: (1) > reintroduce the dedicated bitmap pretty printer(s) I have no problem with that, at least it will work again. Thanks for the review, Maurizio Lombardi