leni536

Joined 12 years ago

Karma

4,532

Submissions

1,878

Member since

Mar 11

Software Developer, PhD Physicist

hn at lenardszolnoki dot com

View on Hacker News

Recent submissions

Comment · 1 day ago

I would be nervous moving borders with ~1 million dollars worth of gold.

Comment · 2 days ago

Shareware/freeware?

Comment · 2 days ago

Understandable. Still not open source.

Comment · 2 days ago

Pdfium powers Chrome's/Chromium's PDF viewer, but maybe Chrome doesn't expose encrypting PDF documents as a feature to be affected?

Comment · 8 days ago

Just call them telescreens.

Comment · 9 days ago

I opened the blocklist expecting some juicy Linux ISO sites and... it's all betting sites. I'm not even mad.

Comment · 12 days ago

Bullets are probably more economical.

Comment · 14 days ago

Ah, the British Museum.

Comment · 15 days ago

Because it's a shape rotation, not a selection rotation. I was confused for a minute too.

Comment · 15 days ago

Actually, no, your copy of C++23 doesn't match mine:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n49...

This is indeed from the C++20 paper P1236R1:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p12...

Comment · 16 days ago

Huh, I stand corrected. It is defined in the current draft though:

https://eel.is/c++draft/expr.shift

I thought this was part of the guaranteed two's complement change in C++20.

Comment · 16 days ago

That is not a primary goal. There was a discussion about "assume" semantics, but that is not one of the standardized contract evaluation semantics.

Comment · 16 days ago

To be fair, direct debit also terrifies me. But I use that one.

Comment · 16 days ago

> Can I please have a language that actually has bitwise operators with defined semantics?

C++? It has defined semantics since C++20.

Comment · 16 days ago

There is already a precedent for a signed integer operation to produce an implementation-defined value or to trap. It's for integer conversion:

https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subsu...

> Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

There is no reason that this wording strategy could not be reused for bit shifts.

In general there is no constraint that unspecified or implementation-defined behavior can't be a trap. Without further qualification "unspecified behavior" or "implementation-defined behavior" is still open-ended, and it's up to the surrounding standard text to restrict the behavior further.

https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subse...

> behavior, that results from the use of an unspecified value, or other behavior upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance

"Possibilities" include trap