Sorry, but I'm must write that: "the internet is full of Europeans expressing anti-Americanism" This strongly sound like Russian "the others country is Russophobic".

Internet mems site are not trustworthy, I'm saying this as Polish, basing on this kind of site I've should be the racist, but I'm not.

Poland was strongly pro american (at least in the last 35 year). Unfortunately, internet in this time must be readed with "grain of salt", there is too many trolls, bots and boring kids.

"I don't think it is just online, but the internet made it very clear to the US how Europeans feel about us." In my opinion there is somekind of "disinformation attack" to quarrel europe with USA, unfortunately, successfully because I see a lot annoyed people on both site.

Information which comes to us via media (tv, local news, etc.) probably are diffrents that this whats you get, so probably this is why you can feel that we're anti-american, but in my opion Europe and USA was in symbiosis not only economically.

I'm also want to mark that Trump from my perspective starting "false flag" operation on greenland, like Putin did that with Ukraine, what woring me because I just don't want a war :)

Sorry, for my English, but for me it's 2:18

I don't think it is internet trolls. It's been going on for a long time. I don't think a disinformation attack would be used on Hacker News. The accounts I'm arguing with have significant karma. And I don't see other Europeans arguing with the ones who express anti-Americanism, or downvoting those comments. That suggests they silently agree.

I don't think the US should be invading other countries. I agree that justifies anti-Americanism, as I stated elsewhere in this thread.

Unfortunately, it's a "bobble", politican topics always cause emotions and annoying, a lot of (if not the most) peoples when see this kind of discussion mostly don't read them for peace of mind.

My wife when is bored, usually, reading twitter and after 15min I'm hearing her crying how people are cruel for animals, but she doing that herself everytime.

The best what you can do is temporary cut off yourself from "bubble", but basing on how intesive news was last time it can be hard.

Human under emotions doesn't thing clear.

When I was in the dormitory (~6-8 years ago), I used VPN (OpenVPN on my private VPS) over UDP port 53 to omit the firewall which was configured to block big parts of ports.

Oh wow that takes me back. I remember complaining to the university that I couldn't download files via FTP. A few months later they answered me explaining file sharing protocols had no legitimate uses at a university. I was working in a research lab and needed to download standardized datasets to validate that the software worked as intended. At the time, only FTP was used.

2x yubico key and bottle of caol ila 12yo

C++ :)

  #include <iostream>
  #include <limits>
  
  double midpoint(double first, double second) {
    auto firstAsInt = reinterpret_cast < int64_t & > (first);
    auto secondAsInt = reinterpret_cast < int64_t & > (second);
    auto mid = (secondAsInt + firstAsInt) / 2;
    return reinterpret_cast < double & > (mid);
  }
  
  int main() {
    std::cout
      << "1.0 <=> 1.5 = " << midpoint(1.0, 1.5) << "\n"
      << "0.0 <=> inf = " << midpoint(0.0, std::numeric_limits < double > ::infinity()) << "\n";
  
    return 0;
  }

Rant:

Technically, that code invokes undefined behavior as you use `reinterpret_cast` to alias variables. The only standards conforming way (prior to `std::bit_cast`[0] in C++20) was to use `memcpy`.[a] `reinterpret_cast` was added for situations where code you have no control over requires a certain type, but you need to force it to take your variable.[b]

[a]: As `memcpy` (in addition to reinterpreting bits) copies the bits (although a compiler will most likely optimize it out), it doesn’t violate aliasing rules.

[b]: This also requires that the code you give your kludged variable to not read out those bits as what it thinks it is (because aliasing). Kindof pointless because: what’s the point of passing a variable that’s never read?

[0]: https://en.cppreference.com/w/cpp/numeric/bit_cast

memcpy certainly violates aliasing rules. You can access an object as an array of bytes, but you can't memcpy an object to one of a different type and then access it as that type without invoking undefined behavior.

Not true. You actually can. Aliasing is about viewing the same bits as two different types (what `reinterpret_cast`, union-based type punning, and cast pointers do) `memcpy` copies the bits to a new location which doesn’t violate aliasing. I don’t have time to find the reference in the standard, but cppreference.com[0] says it’s ok:

> Where strict aliasing prohibits examining the same memory as values of two different types, std::memcpy may be used to convert the values.

[0]: https://en.cppreference.com/w/cpp/string/byte/memcpy

Who is cppreference.com? The domain registration is concealed, just like that of the other dubious site, cplusplus.com.

I don't see any such a claim about memcpy having magic powers in the N4659 C++ draft.

All it says is that the underlying bytes of an object can be copied to an array of char, unsigned char, or std::byte. Then if that array is copied back into the object, the object subsequently holds its original value.

Anything more about memcpy comes from C by reference, and that would be about the last document on Earth to grant definedness and portability to something like this.

memcpy() by itself cannot violate aliasing rules. By definition, char can alias any object.

Whether you can access an object that has been memcpy()'d into is a separate question. I can't find specific language about this, but I strongly suspect that the result is implementation-defined or unspecified (not undefined), unless there is a possibility of a trap representation.

This remark doesn't appear to add anything to my original unedited comment, which includes the clarifying words "you can't memcpy an object to one of a different type and then access it as that type without invoking undefined behavior".

My reading of section 8.2.1 suggests that it is not UB to copy bytes from an object of one type to an object of another type, and then to read the value of the second object, since it is explicitly allowed to access each object as bytes.

It being well-defined to access an object as an array of bytes doesn't add up to it being well-defined to access a whole object as an lvalue of any type. Type aliasing rules do not work this in this constructive way.