https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
--- Comment #22 from manu at gcc dot gnu dot org 2008-01-16 12:36 ---
(In reply to comment #21)
> (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 agr
--- 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, wh
--- Comment #20 from manu at gcc dot gnu dot org 2008-01-15 21:49 ---
(In reply to comment #19)
> (In reply to comment #17)
> > This will be fixed yesterday if printf("%s\n", s) were equivalent to
> > puts(s) in
> > glibc.
>
> [+] The standard requires them to be equivalent? Per standa
--- Comment #19 from gustavodn at gmail dot com 2008-01-15 21:08 ---
(In reply to comment #17)
> This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s)
> in
> glibc.
[+] The standard requires them to be equivalent? Per standard, they can't be
equivalent if both ar
--- Comment #18 from manu at gcc dot gnu dot org 2008-01-15 20:48 ---
There is an explanation for the optimisation, a potential fix [*] and there is
a workaround.
[*] http://sourceware.org/bugzilla/show_bug.cgi?id=5618
--
manu at gcc dot gnu dot org changed:
What|Rem
--- Comment #17 from manu at gcc dot gnu dot org 2008-01-15 18:51 ---
This will be fixed yesterday if printf("%s\n", s) were equivalent to puts(s) in
glibc.
Also there is a way to disable the optimization: "-fno-builtin-printf".
People that don't rely on undefined behaviour don't deser
--- Comment #16 from gustavodn at gmail dot com 2008-01-15 17:20 ---
"Glibc being Linux being the world" is not really relevant, IMHO. What is
relevant is printf() (or any function) is, fundamentally, implemented by
library, not by compiler, so compiler should not prevent library from de
--- Comment #15 from pinskia at gmail dot com 2007-11-16 22:11 ---
Subject: Re: too agressive printf optimization
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither
> Is there any difference in the standard behaviour between printf("%s", NULL)
> and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
> but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
No both are undefined.
-- Pinski
--- Comment #14 from manu at gcc dot gnu dot org 2007-11-16 16:17 ---
Is there any difference in the standard behaviour between printf("%s", NULL)
and puts(NULL)? I mean, why printf("%s", NULL) receives special consideration
but neither puts(NULL) nor fprintf(stdout, "%s", NULL) do?
Any
--- Comment #13 from joseph at codesourcery dot com 2006-01-01 22:18
---
Subject: Re: New: too agressive printf optimization
On Fri, 30 Dec 2005, drepper at redhat dot com wrote:
> There should at least be a mode in which gcc does not perform the
> transformation if it cannot be sur
--- Comment #12 from drepper at redhat dot com 2005-12-31 00:19 ---
> That is not true at all and you know that. There is uclibc.
Now you've completely given up on logic? First of all, uclibc and whatever
other libc immitation is out there does not define the linux API. glibc *is*
th
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-12-30 23:49
---
(In reply to comment #10)
> glibc *is* the world as far as Linux is concerned.
That is not true at all and you know that. There is uclibc.
This is still undefined code even if the underlaying printf defines it.
--- Comment #10 from drepper at redhat dot com 2005-12-30 23:44 ---
glibc *is* the world as far as Linux is concerned. You consistently and
deliberately misinterpret what I write: I'm not talking about any platform
which does not use glibc or glibc's behavior.
And RTH already concurred
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-30 23:36 ---
I should note that glibc is not the world.
Also the patch which added the transformations:
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00826.html
If you see that RTH approved it without any objections.
I still s
--- Comment #8 from drepper at redhat dot com 2005-12-30 23:14 ---
> That is true but GCC is a C compiler and not a glibc implemention C compiler.
This doesn't mean anything. As soon as you configure gcc to target it to Linux
the behavior of the runtime is as defined by the C library.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-30 23:08 ---
(In reply to comment #4)
> The standard might leave it undefined but this does *NOT* mean the
> implementation cannot define it.
That is true but GCC is a C compiler and not a glibc implemention C compiler.
--
--- Comment #6 from drepper at redhat dot com 2005-12-30 23:08 ---
This is NOT a dup of 15574.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25609
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-30 23:07 ---
You are wrong.
*** This bug has been marked as a duplicate of 15685 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from drepper at redhat dot com 2005-12-30 23:06 ---
No, it's *NOT* undefined. The libc interface decides what is defined and what
is not and it is *EXPLICITLY* documented that NULL pointers are printed as
(null).
The standard might leave it undefined but this does *NOT*
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-30 23:05 ---
Mark as a dup of bug 15574.
*** This bug has been marked as a duplicate of 15574 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-30 23:05 ---
Reopening to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-30 23:01 ---
The code is undefined so seg faulting is an okay thing to do.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
24 matches
Mail list logo
