Yeah but that's because "trans" is nothing more than a sexual fetish to these men. They objectify women and get off on it, using their own bodies to construct the erotic target.
You’re clinging to a semantic distinction that is meaningless to me. I’m happy and I feel good, and your desire to simplify the meaning of gender transformation in to little boxes you can understand has no bearing on me or my life.
It's not particularly advanced, it's the same thing that means the supermajority of websites have opted for "click here to consent to our 1200 partners processing everything you do on our website" rather than "why do we need 1200 partners anyway?"
It's still bad, don't get be wrong, it's just something I can distinguish.
I think those websites actually have only one partner, one of the tiny oligopoly of advertisement brokers. That partner (*cough*Google*cough*), in turn, bows to the fig leaf of user consent via those interminable dialogs. So the site owners' question should probably be "Why do we need to partner with this behemoth that shackles us to 1200 'partners?".
If it fools billions of people and does significant damage to the lives of people, then it's plenty advanced to me, even if it happens through a more simple or savant-like process than something that looks obviously deliberate.
I don't think the cookies thing is a good example. That's passive incompetence, to avoid the work of changing their business models. Altman actively does more work to erode people's rights.
> It's still bad, don't get be wrong, it's just something I can distinguish.
Can you? Plausible deniability is one of the first things in any malicious actor's playbook. "I meant well…" If there's no way to know, then you can only assess the pattern of behavior.
But realistically, nobody sapient accidentally spends multiple years building elaborate systems for laundering other people's IP, privacy, and likeness, and accidentally continues when they are made aware of the harms and explicitly asked multiple times to stop…
They’re asking why it’s not an attribute on the type instead of on the function. I don’t believe your answer explains that unless I’m overlooking some obvious implication of your statement.
For reasons that are too hairy to go into here C doesn't "really" have a string type (yeah, yeah pendants, I know about fixed strings etc.).
It just has arrays of char, which you pinky promise will end in a \0 for things that expect strings.
By declaring that yes, this function really must have that terminating \0 a sufficiently smart compiler can statically analyze some errant use of functions expecting terminated strings. I haven't looked into this new feature, but I assume that's what it's doing.
If you mean why is the "__attribute__" syntax not declaring such a thing adjacent to the function, the answer is that this allows for shoving the . extended syntax into standard C in a mostly backwards compatible way.
No, I’m asking why you can’t apply this variable on types within a function to verify that for example:
__attribute__((null_terminated)) const char* x = strcpy(maybe_not_null_terminated, “some string”);
Is a warning. Similarly, if it’s a type attribute then you’d apply it on the argument itself instead of needing to specify it on the function + an IDX parameter:
The newly introduced strub attribute works this way, so it’s unclear why a function attribute was chosen for this attribute instead of a type attribute.
Yes, rather poor but people can always post new answers and votes sort the answers. It might not work all that well but there is a mechanism for improvement and to keep things up to date.
Language models can copy the top answers from SO, ingest docs and specs etc. And then the information is never updated? Or are they going to train it from scratch? On what? Outdated github saved games?