> Hi! > > The profile_count::dump (char *, struct function * = NULL) const; > method has a single caller, the > profile_count::dump (FILE *f, struct function *fun) const; > method and for that going through a temporary buffer is just slower > and opens doors for buffer overflows, which is exactly why this P1 > was filed. > The buffer size is 64 bytes, the previous maximum > "%" PRId64 " (%s)" > would print up to 61 bytes in there (19 bytes for arbitrary uint64_t:61 > bitfield printed as signed, "estimated locally, globally 0 adjusted" > i.e. 38 bytes longest %s and 4 other characters). > Now, after the r14-2389 changes, it can be > 19 + 38 plus 11 other characters + %.4f, which is worst case > 309 chars before decimal point, decimal point and 4 digits after it, > so total 382 bytes. > > So, either we could bump the buffer[64] to buffer[400], or the following > patch just drops the indirection through buffer and prints it directly to > stream. After all, having APIs which fill in some buffer without passing > down the size of the buffer is just asking for buffer overflows over time. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Thanks for fixing it! I believe the original reason why dump had the buffer argument was pretty printing, which we do differently now. Fully agree that the fixed size buffer is ugly. Honza
