<div><p> </p><blockquote> By the way, having a RISC-V machine handy:<br /> Linux orangepirv2 6.6.63-ky #1.0.0 SMP PREEMPT Wed Mar 12 09:04:00 CST 2025 riscv64 riscv64 riscv64 GNU/Linux<br /> I've tried:<br /> SELECT int4shl(1, 100);<br /> int4shl<br /> ---------<br /> 16<br /> (1 row)</blockquote></div><div> </div><div>Yes, my mistake, I rechecked the manual this instruction should not cause a trap.</div><div> </div><div><blockquote><div>FWIW, I don't agree with the premise of this patch, even a little bit.<br />To my mind, the purpose of these functions and their siblings is to<br />provide access to the C-level bitwise operators, which will do<br />whatever they do on your platform. There is no contract to restrict<br />them to some guaranteed-portable functionality subset, and I think<br />trying to do that would accomplish little except to break code that<br />had been working fine in the context it's used in.</div></blockquote></div><div> </div><div>Ok, I understand that compatible behavior is not a priority in this case.</div><div><br />Still an UB can be optimized and exploited by compiler in any way it decides,</div><div>so we don't have a guarantee that current platform behavior will stay.</div><div>What is a general postgres community policy about UBs?</div><div> </div><div>Regards,<br />Egor Ivkov</div>