> All users of %n are calculating padding size when using seq_file, so > instead use the new last_len member for discovering the length of the > written strings.
Obviously, this comment needs to be updated, but once that is done, Acked-by: George Spelvin <[email protected]>. I actually reviewed all the users and checked that things work properly. In the various VMA map and tcp state lists, the line width (128 or the now-misnamed TMPSZ=150) is greatly in excess of what's required, presumably to facilitate computing the iteration index from the file position in pre-seqfile days. If the line were to ever get longer than that, the semantics of printf("%*s", -5, "") would give strange results, but that's a pre-existing problem that is unlikely to occur, would probably be harmless (as would deleting the trailing whitespace!), and isn't made any worse by this. HOWEVER, it gave me an idea. We could put this padding logic straight into vsprintf and clean up all the callers. I'm currently thinking that a precision specifier in %c (%.*c) is currently meaningless and ignored. What if we usurped it and defined it to mean "pad with this character until the total width so far this rint reaches the specified precision"? That would DTRT for all the callers. Oh, bugger, gcc -Wformat warns about doing that. And %#127c. And everything else I can think of. The only way to sneak it past gcc would be to usurp the rarely-used %-127c format. Since the only pad character currently used is space, we could omit the argument and use something like %127%, but gcc gets even more confused by that. The code is easy enough. But any suggestions for ways to represent it in the format string would be appreciated. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
