This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/25609] too agressive printf optimization
- From: "gustavodn at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Jan 2008 01:52:19 -0000
- Subject: [Bug rtl-optimization/25609] too agressive printf optimization
- References: <bug-25609-700@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #21 from gustavodn at gmail dot com 2008-01-16 01:52 -------
(In reply to comment #20)
> Anyway, if you really want to believe that printf("%s\n",s) and puts(s) should
> not have the same effect for defined behaviour, then we will have to agree to
> disagree.
That's confused, what is being discussed is undefined behavior X optimization
trusting it. Still, the manpage for puts() says "output of characters and
strings", while the one for printf() says "formatted output conversion". puts()
just sends a string to stdout, printf() converts data into their string
representation. So I agree to disagree about the expectation on what they do
about NULL: puts() should do nothing or merely return error, while printf()
*could* convert or otherwise print a string representation of it.
Given the impasse, and given Glibc defines what it does, I understand the next
correct thing for someone who cares to do, is to report a bug on GCC about this
issue on any specific distributions using GCC together with Glibc.
cya
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609