On Tue, 26 Mar 2024 22:55:29 +0300 Nikita Kiryushin <kiryushin@xxxxxxxx> wrote: > On 3/26/24 22:22, Steven Rostedt wrote: > > Why 87? as it's not even word size, and this is on the stack. > > > Got 87 as maximal used buffer length (result of > sprintf(buf, "N%lu h:%lu/%lu/%lu", > (unsigned long int) -1, > (unsigned long int) -1, > (unsigned long int) -1, > (unsigned long int) -1); > +1 for terminator. > > Is word-size alignment a thing in this case? I thought that char buffers > are ok to be aligned by 1? Because it's on the stack, which will likely reserve data in word size. Thus, buf[87] reserves as much data on the stack as buf[88]. > > Better yet, why not just use snprintf()? > > > Seems like a better idea indeed, as if fixes overflows for unpractical cases, > without added overhead to common cases. The only concern is possible truncation > of data, that may break some automation (if output is parsed by someone, > without accounting on it being cut, who knows). But again, it is for pretty unpractical > values. > > Will make a v2 patch with snprintf() with buffer length. > > Genuinely look forward to being educated about aspects of aligning array sizes, as > I do not really understand the limitations. It's because it's on the stack, but it's always good to align. For instance, kmalloc() will allocate things in 32 byte chunks. -- Steve
