hvdijk

Except that the HTML spec explicitly states just before that regex that what it checks is not whether it's a valid e-mail address, and that it intentionally rejects valid e-mail address.

> The right to free speech does not protect your right to commit crimes or [...]

If hate speech were to be made a crime, your exact same argument "the right to free speech does not protect your right to commit crimes" could and would be used as an argument why the First Amendment supposedly does not apply.

> It neither helps cause physical damage nor costs the victims money. You cannot, in the US, ban the expression of a thought just because you think somewhere down the line it could result in damage to someone.

That is exactly what your example of planning to rob a bank is. The planning to rob a bank does not cause any damage. The planning to rob a bank does not cause any victims any money. Actually executing that plan does that, but the planning does not guarantee that the execution will happen. Yet if I were to say "You cannot, in the US, ban it just because you think somewhere down the line it could result in damage to someone" you would rightly dismiss it as nonsense.

> Hate speech is mostly just hurting peoples feelings.

We may disagree on the "mostly", but even you are acknowledging that it is not limited to that, so let's focus on cases that can't be considered that.

> Libel is a tort because you lie (important) to damage someone's reputation and this could cost them money.

Okay, now consider for instance well-known conspiracy theories that the world is controlled by (insert group here). They are lies, they damage the reputation of many if not most members of the group, and this could cost members of the group money. They are not libellous if not said about specific people, they are generally considered hate speech if based on any of a specific set of protected characteristics, but despite the exact same reasoning applying to both, libel would not be considered protected speech, and, as far as I understand, this particular form of hate speech would be.

It is also easy to think up scenarios where supposedly constitutionally protected hate speech "helps" cause physical damage: if without the hate speech, a group of people would be left alone, but with the hate speech, other people become convinced that it is morally defensible or even necessary to commit crimes against those people.

I can see no distinction in the constitution to justify this. I understand that this is how US courts interpret the constitution, but everything I can see tells me this is an arbitrary distinction drawn up by US courts with no actual basis in the constitution.

The US First Amendment does not say anything about libel or calls to violence. I am not aware of other amendments doing so either. What is the rationale for allowing these limitations on speech that cannot equally be applied to hate speech?

True. And that still doesn't mean the behaviour is undefined, that just means the construct is not useful except on two's complement implementations. Which, even before C23, was all of them: the C23 change to require two's complement wasn't really meant to invalidate existing implementations, it was meant to reflect the reality that there were no other implementations worth considering. See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm, the only non-two's-complement implementation still in use that was found was very much a legacy-only thing for backwards compatibility where it was not expected that its users would want a modern C compiler anyway.

Are they UB? What rule says they are? I would not be surprised by such a rule, but I am not aware of one.

> You really just want the calculation to be settled with some well-behaved result like wrapping, or else to raise an exception.

Perhaps you do, but others don't. This compiler behaviour isn't done just for the hell of it, it's done because it's an unavoidable consequence of optimisations that some people rely on that improve performance of valid code. At the same time, other people have almost-valid/invalid code (call it what you will) that behaves as intended when less-optimised, but breaks under these more aggressive optimisations. Whether to prioritise the handling of valid or invalid code is something people will never agree on; everybody will say to prioritise the handling of the type of code that they themselves wrote. I think compilers made the right call in having this as an option so that people can choose what works best for them.

Correct, and the article does consistently spell it 3DO, it's only the link title here that uses 3D0.

The Wikipedia article you link to also claims that the 1882 Oxford Etymological Dictionary of the English Language said that one meaning of gender was sex. Other dictionaries from well before 1955 also support this. In fact, the 1828 Webster's dictionary, available online, specifically says the meaning of sex came first, the meaning in grammar followed from that. The separation of sex and gender is recent, you're right about that and that's what I was saying too, but you're wrong that sex was the only term used before that.

> I thought trans was about changing gender, not changing sex.

Mostly true, but it's confusing. Historically, sex and gender have been used interchangeably. That is slowly changing. There are a lot of places that refer to "sex" where "biological sex", as you put it, is not what is meant. See e.g. how trans people can still get their "sex" updated on documents that refer to sex and not gender, and how many places described as single-sex are actually closer to single-gender.

If you know it's controversial, we now know "not one that would generally be considered offensive for others to mention" was, at best, being disingenuous. Is there anything else?

That explanation is directly ruled out by GP's comment: the GP doesn't think this is controversial.

The lawyer did work, thankfully.

It isn't guilt by association when the article directly uses anti-trans rhetoric.

I'm glad your experience was better than mine. I had to get a lawyer involved after the Dutch support told me I would be refunded if I returned an item, and then after I sent it back, denied the refund.

There's no "could be seen as", the phrase "sex realist" makes it clear beyond any doubt that the author does support the activities of Colin Wright.

That's fine if the script only runs on shells that behave the same way, but the script runs under bats, which runs on bash and appears to not change its xpg_echo shell option. This shell option controls echo's behaviour on bash and has a compile-time-configurable default; even scripts that are only meant to run on bash cannot assume either behaviour for echo, as different vendors use different defaults for the option.

The script does echo variables:

    echo "banned command $cmd: $output"

This is non-portable if there is any possibility that these variables contain backslashes.

And flagged this for it. No tolerance for this kind of crap, the guidelines are clear, the original title being false or misleading is when you shouldn't use the original title. The author took a calculated risk. Without the clickbait, some would never have seen it. With the clickbait, others such as myself will resent them for it. I hope for his sake he made the right choice.

That's a bug, there is no such thing as an invalid trigraph. ?? followed by any character other than =, /, ', (, ), !, <, >, or - is not a valid trigraph, but that doesn't make it an invalid trigraph, that just makes it not a trigraph, it's perfectly valid to have ??? in a comment, or in a string literal.

Ah, thanks for the clarification, I think we've been talking about two slightly different things, then. For you, std::optional would have to make C++ more memory-unsafe than it already is in order for "anti-memory-safety" to be a fair characterisation. For me, that label merely implies that memory-safer alternative designs of std::optional were considered, and the current design was picked despite its memory-unsafety being a known potential issue. I think I would likely agree with you that std::optional does not make C++ less memory-safe than it already was before that got added.

> But your "facts" are "if I use the API wrong, it behaves wrong."

Kind of, yes. That is what memory safety is about, isn't it? If I look for definitions, I find for instance <https://hacks.mozilla.org/2019/01/fearless-security-memory-s...>, explaining it as:

> When we talk about building secure applications, we often focus on memory safety. Informally, this means that in all possible executions of a program, there is no access to invalid memory. Violations include:

> - use after free

> - null pointer dereference

> - using uninitialized memory

> - double free

> - buffer overflow

std::optional does not itself protect against using uninitialised memory, it merely provides the tools by which the programmer can prevent using uninitialised memory. Isn't that exactly what memory safety is about, about having std::optional somehow automatically ensure that that doesn't happen? If that isn't what memory safety is, what, in your opinion, does it mean instead?

Note that I have attempted to refrain from posting my opinion on whether C++ made the right call or not. That is a separate question from whether it qualifies as memory-safe.

Sure, std::optional<int> is unlikely to result in such behaviour in practice, and std::optional<int*> is likely to "only" result in such behaviour if the result of operator*() is dereferenced again, despite both already being UB. Think of non-POD types, such as std::optional<std::string>, though: when you end up using uninitialised std::string objects, things do break in practice because of pointers used internally to implement std::string, and badly so.

The fact that checked versions exist but are not used by default, have to be explicitly opted into, is consistent with C++'s designs and may be used to defend the current design, but at the same time also means it describing std::optional as memory-unsafe becomes a valid opinion based on facts, I think.

std::optional can be described as memory-unsafe because indirection when an optional is empty has undefined behaviour rather than deterministically throwing an exception or aborting the program, and may misbehave in all sorts of spectacular ways, including accessing random memory, on common implementations. Thankfully, implementations can and do provide ways to get it to behave more predictably.

More to the point, as usually happens in India.

The only reason the article gives for using this over using the signing with GPG keys is that you will have an SSH key already. If you need to create a new key, are there any reasons for going for an SSH key over a GPG key?

Even /bin/sh is not guaranteed to exist, and when it does exist, it is not guranteed to be useful. It is not a location specified by POSIX, and implementations exist that do not place the standard sh utility in /bin. The big one was SunOS/Solaris, where /bin/sh did exist but was the pre-POSIX implementation, and /usr/xpg4/bin/sh existed for when you wanted POSIX sh. Android puts it in /system/bin/sh and not all of them have the compatibility symlink /bin -> /system/bin. There are probably other special cases as well.

POSIX explicitly says "Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH [...]"

> famously ij in Dutch

ij is considered two letters in Dutch, although they go by special rules: https://onzetaal.nl/taalloket/ij-plaats-in-alfabet

Labels would be more readable for that IMO:

    outer:
    for (...)
      for (...)
        if (...)
          break outer;

It turns out it's actually pdpmake-build-time-configurable. If you build with -DENABLE_FEATURE_MAKE_EXTENSIONS -DENABLE_FEATURE_MAKE_POSIX_202X, extensions are enabled by default, and .POSIX only flags non-POSIX-202x extensions. I don't know what, if anything, this says about the main point of pdpmake, but I'm glad with this mode.

It depends on the package. As far as Autotools itself are concerned, yes, users are free to choose whether to do in-tree or out-of-tree builds, but some packages require one or the other.