https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to jos...@codesourcery.com from comment #9) > Implementation-specific can in practice include cases where the > implementation deviates from the standard (e.g. Windows 3-digit exponents, > though disabling the optimization for floating-point formats should hide > that). It's clearly not a good idea to convert a minor conformance bug in > the library into a buffer overrun by causing a program to allocate enough > memory for the standard output from a format but not enough for what the > library implementation actually outputs. > > (It wouldn't surprise me if there are printf implementations whose results > for some floating-point values are not one of the nearest decimals in each > direction and so could take more characters than either of those take in > some cases.) Yeah, that is what I don't like on -fprintf-return-value either. Warning if in certain cases the GCC assumption on what the library will actually do is not 100% matching the library implementation is one thing, but the optimization (which I'm not sure is really that beneficial in most cases) is just too dangerous, perhaps with the exception of the safest cases (no % characters, or just %s with known non-NULL strings, or perhaps some easy integral cases). There are many library implementations, and not all of them match the spec 100%, and the current GCC implementation of the optimization doesn't match it 100% either.
