Comment 10 for bug 946758

I understand that it's not perfect, but this is the fix that is upstream and in Quantal. If we wanted to fix the problem differently from upstream, we'd need to also do it in Quantal and carry a delta as a minimum, and ideally forward the patch to upstream as well.

The format string is 39 bytes long, less two '%d's so 35 (excluding the null terminator). It does not appear to be i8n-ised. How did you get 41?

"%d" expects a plain int, which is still 32 bits on amd64 on Precise. And mismatch_cnt is a plain int, so 32 bits too. Or is there an option somewhere that is making ints bigger? And the second %d is just the raid level, which I don't expect to be bigger than two decimal digits anyway.

Even if the %d did expand a 64-bit number, then it'd expand to at most 20 bytes (including the sign). Assuming that the raid level is at most two bytes, the string would be a maximum of 58 bytes including the null terminator, which is less than the 80 now allocated.

Even if both %ds expanded full 64-bit integers (just in case the user happens to be using a RAID level of -9223372036854775808), that'd be 35+40+1=76 which is still under 80.

I'm just following the path of least resistance by doing what upstream has done. We can go beyond that if necessary, by patching Quantal and ideally upstream as well. I don't it is necessary here, but I'd appreciate input from a sponsor on this. If you care, then a new upstream bug and patch would be appropriate.