Messages in this thread | | | Date | Thu, 10 Sep 2015 11:47:06 -0400 | From | Tejun Heo <> | Subject | Re: [PATCH] lib/vsprintf.c: increase the size of the field_width variable |
| |
Hello, Joe.
On Thu, Sep 10, 2015 at 08:41:25AM -0700, Joe Perches wrote: > On Thu, 2015-09-10 at 10:36 -0400, Tejun Heo wrote: > > On Wed, Sep 09, 2015 at 12:26:39PM -0700, Joe Perches wrote: > > > > > %*pb is meant for smallish bitmaps, not big ones. > [] > > The use case isn't from me, but why not? > > Imagine the output of the 500k bitmap if every other > bit is set.
Yeah, but the caller still should be able to call, say, scnprintf() with a limited buffer and get the output till the end of the buffer along with the indication that the output has been truncated.
> %*pb isn't capable of multiple line output and > seq_printf output would also fail as it uses k.alloc > memory not vmalloc.
Heh, and it should fail.
> I think that a more limited mechanism might be to use a > multiple line oriented function like print_hex_debug > and not try to emit the entire thing in a single go.
I'm not that worried about the berserk cases which try to print a really long output on consoles but the subtle failure modes are worrying.
> > Why are we even copying the struct on invocations? > > Only some functions modify the values after all. > > We might as well pass around pointer to the struct > > and let the callees wihch modify them copy the > > fields in local vars like normal functions. > > You are of course welcome and able to change it. > > btw: the current implementation has a limitation > on 32 bit arches as it uses an int argument for the > unsigned long count of bits in a bitmap. > > That's a bitmap that should not be printed anyway.
That's 256Mbytes of bitmap. I don't think we need to worry about that at the moment.
Thanks.
-- tejun
| |