@MSGID:
aa011052
@REPLY:
<20230926103830.cb69a2ff5b91dbc09825bc4f@127.0.0.1> 80f450a3
@REPLYADDR none) (albert
@REPLYTO 2:5075/128 none) (albert
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<6363a6bb-7a1a-4289-9883-d4e9b5569a3e@googlegroups.com> 1@dont-email.me>
<72540e7d-0866-4a1c-9067-84305c171250n@googlegroups.com> <20230926103830.cb69a2ff5b91dbc09825bc4f@127.0.0.1>
@RFC-Message-ID:

@TZUTC: 0200
@TID: FIDOGATE-5.12-ge4e8b94
In article <20230926103830.cb69a2ff5b91dbc09825bc4f@127.0.0.1>,
Kerr-Mudd, John  wrote:

>I`m no C programmer, (nor even much of a Forth one) but I`ve heard of some
>who got a right roasting in clc, back some years ago - seems some compiler
>writers decided "undefined behaviour" meant they could mess up the
>intentions of a coder with delight.

And they are. However the correct interpretation is that if a programmer
does not make its intentions clear, the compiler builder could go
out of its way to find that situation out, but they don`t.
A C++ compiler is sufficiently complicated that this is not doable
anymore. One of the way out is to simply forbid "undefined behaviour",
meaning that in all circumstances the compiler generates a program
that behaves the same in all situations.
Actually this means that *all* compilers force the program to behave
the same on *all* systems. The industry is not willing to pay the
price for that.

Hugh
-- 
Don`t praise the day before the evening. One swallow doesn`t make spring.
You must not say "hey" before you have crossed the bridge. Don`t sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning.            - the Wise from Antrim -
--- trn 4.0-test77 (Sep 1, 2010)
 * Origin: KPN B.V. (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441