As far as I understand: The exception throwing for invalid data would be specifically guaranteed by some implementation or debug version of a standard library. So the implementation would specification-wise fill out the UB from the standard for specific cases. So it is not actually waiting for UB. (Or only UB by the standard, but DB (?) by the specific implementation.)   For your list:  - how about objects without vtables  - and unions which remember their active member   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 21.12.2023 20:25 Betreff:Re: [std-proposals] Lakos rule An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Thursday, December 21, 2023, Ville Voutilainen wrote: The implementation can do anything, including throwing an exception.   Okay I understand now. The implementation will only violate the Standard after you as the programmer have warranted it to do so by invoking undefined behaviour (and therefore it's not really violating the Standard because it can do whatever it likes).  To be doubly sure and deliberately paranoid, when writing portable code to run on everything from an 8-Bit single-core microcontroller to a multi-core 64-Bit supercomputer, maybe wrap 'std::align' in a wrapper that catches and calls terminate. (I mean just to cover yourself sort of like casting to an 'unsigned char' before invoking 'std::tolower').  Personally when I'm writing bullet-proof code, I just put many 'assert's throughout the code. I would assert that a vector is non-empty before calling 'front()'. If I want to handle bad input from the user or corrupt data from a socket, I throw an exception. I don't see myself ever waiting for UB to be invoked and then relying on a particular implementation's flamboyant use of its warrant to do whatever it wants. The whole Lakos thing isn't my cup of tea, but hey it seems a lot of intelligent people like it.  When I want to torture test a program of mine, I use a cross-compiler to build it for 32-Bit Big Endian ARM, and then I run it in the Qemu CPU emulator on my 64-Bit Little Endian x86 desktop PC. If the emulator runs the program perfectly then I'm probably onto a winner.  One day I'd love to write a very bizarre CPU emulator and compiler that does all sorts of weirdness:      sizeof(char*) > sizeof(int*)     negative numbers == One's Complement     CHAR_BIT == 11     integer types contain padding bits     null pointer is all bits 1  I'd use this setup to torture-test programs.                -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals