This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Optimisations and undefined behaviour
- From: Vincent Lefevre <vincent+gcc at vinc17 dot org>
- To: gcc-help at gcc dot gnu dot org
- Date: Mon, 9 Nov 2015 22:59:34 +0100
- Subject: Re: Optimisations and undefined behaviour
- Authentication-results: sourceware.org; auth=none
- References: <563BC190 dot 7080406 at hesbynett dot no> <563C7EB6 dot 9050401 at redhat dot com> <563C9DD3 dot 9030407 at hesbynett dot no> <563F9E4C dot 5000504 at redhat dot com> <20151108193430 dot GA28206 at gate dot crashing dot org> <56407162 dot 7050106 at redhat dot com> <56408D14 dot 2090101 at redhat dot com> <5640A8D3 dot 8060706 at redhat dot com> <5640AAC5 dot 9090509 at redhat dot com> <5640ADC5 dot 4090604 at redhat dot com>
On 2015-11-09 14:29:25 +0000, Andrew Haley wrote:
> Here it is again:
>
> int foo(int x) {
> if (x > 1290) {
> printf("X is wrong here %d, but we don't care\n", x);
> }
> return x*x*x;
>
> Here, the printf writes to a stream then the UB happens. But the
> stream is buffered and the UB kills the process before the stream is
> flushed. There is nothing in the C specification to prevent this, and
> neither should there be. I don't think it's even possible.
But it may happen that the buffer is full, so that the stream will
be flushed and the printf can block forever (e.g. is the user pipes
the output to a process that doesn't read anything) so that the
"return x*x*x;" is not reacheable for this particular instance.
So, in this case, the UB never happens.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)