On 11/09/2015 03:05 PM, Richard Earnshaw wrote:
> On 09/11/15 15:00, Andrew Haley wrote:
>> On 11/09/2015 02:56 PM, Richard Earnshaw wrote:
>>> On 09/11/15 14:29, 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.
>>>
>>> Not if setvbuf has been used to make the stream unbuffered.
>>
>> It hasn't. And I know it hasn't because it's my example.
>
> A compiler would still need to do whole-program analysis to prove that;
> it can't work on the assumption that it hasn't been done.
I'm not sure about that: see below.
>> And besides, the UB might cause the computer to crash before the
>> data has been written to stdout by the kernel; the same reasoning
>> applies.
>
> UB that causes the machine to crash is, I think, outside of what we need
> to think about. Any machine that's falls over in that case is not
> interesting.
Well, in that case you'll have to define what you think we are
supposed to be thinking about. I don't think you are talking about
the C language as it is specified, you're talking about some
implementation on some machine, and of course I can't argue with you
about what that machine does because I don't know anything about it.
Such a discussion is IMO pointless because everyone can just Make
Stuff Up.
I do know that once UB has happened in a program, the whole program is
undefined and the language specification imposes no requirements on it
at all. I don't see any language in the specification which requires
prior operations with side effects to have completed.
But should we treat all potential UB as having a side effect,
(essentially treating it like a volatile) so that it cannot be moved
past a sequence point? I wouldn't have thought so, but perhaps we
could.
Andrew.
