2,295 karma · joined March 20, 2012
Apparently XCancel is an instance of Nitter. According to Wikipedia, "Nitter is designed to allow access to X without tracking, advertisements, or the need for an account. It only supports browsing, and cannot be used to sign in or interact with the X community."
Similarly, if a button has recently moved, wait a little while before activating it. (Better yet, arrange for things not to move around as the page is loading.)
It should be on a separate line.
#!/bin/bash eval "$(base64 -d <<< '...The labor theory of value says that the value of something is determined by the amount of labor that went into creating it. I'd say it's not really so much a theory as a definition of the word "value" -- and I suggest that it's not a particularly useful definition.
If I go to the widget store to buy a widget, the price I'm willing to pay depends on what it's worth to me. The amount of work that went into producing this widget or that widget doesn't affect my decision.
Another article you might (or might not) want to read: https://en.wikipedia.org/wiki/Criticisms_of_the_labour_theor...
"Get rid of copyright, and the market simply becomes fair."
I think the word "simply" is doing a whole lot of work there.
Isn't it?
If you spend ten years writing the Great American Novel, and I spend ten years writing "All work and no play makes Jack a dull boy" over and over again, have I created as much value as you have?
https://en.wikipedia.org/wiki/Labor_theory_of_value#Critique...
This was reversed for the first standard, which ANSI published in 1989; ISO adopted it, with editorial changes, in 1990. The term "ANSI C" usually (not entirely correctly) refers to the 1989 standard. If you want to refer to a particular version, it's best to refer to "ISO C" and the date (1990, 1999, 2011, 2023).
The money you pay for a copy of the standard doesn't go to the people who do the work of writing it, who are either volunteers or paid by their employers.
My understanding is that authors often have little or not control over the covers chosen by their publishers.
It's at least possible that the book itself is excellent, but I'm not going to spend $90+ on a hardcover copy to find out.
A conforming implementation could reject it at compile time, or generate code that traps, or generate code that set a to 137, or, in principle, generate code that reformats your hard drive. Some of these behaviors are unlikely, but none are forbidden by the language standard.
int a = 5;
int b = a++;
Giving 13 for a++ + ++a is not a bug in the compiler. It's a bug in the code.
The correct answer to "what does a++ + ++a do" is "it gets rejected in code review and replaced with code that expresses the actual intent.
If you write:
int i = 0;
i = i++;
If you print the value of i, the compiler can still optimize away the computation, but is perhaps less likely to do so.
The solution, of course, is not to write code like that. Decide what you want to do, and write code that does that. "i = i++" will never be the answer to "how do I do this?", and wouldn't be even if the behavior were well defined. If you want i to be 1, write "int i = 1;".
As a programmer, the solution to "int a = 5; a = a++ + ++a;" is to decide what you result you wanted, and write code that will produce that result, and probably to pass options to the compiler that tell it to detect this kind of problem and print a warning. (On my system, the result happens to be 12; if that's what I want, I'll write "int a = 12;").
But if you have an existing program that includes that code, it can be useful to look into the actual behavior (for all the compilers that might be used to compile the code, with all possible options, on all possible target systems). Fixing the code should be part of that process, but you might still have running systems with the old bad code, and you need to understand the risks.
But producing some numeric result is not the only possible behavior, even in real life. Compilers can assume that the code being compiled does not have undefined behavior, and generate code based on that assumption. The results can be surprising.
As for formatting your disk, that's not just a theoretical risk. If a program has enough privileges that it can format your disk deliberately, it's possible that it could do so accidentally due to undefined behavior (for example, if a function pointer is corrupted).
The behavior of "int a = 5; a = a++ + ++a;" is undefined. There is no guarantee of a numeric result, because there is no guarantee of anything.
<https://git-scm.com/book/en/v2>
"Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. Thus, an organic SHA-1 collision is less likely than every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night."
Deliberate collisions are addressed in the following paragraph.
SHA-1 hashes are not random, so the issue of poor pseudo-random number generation doesn't apply as it does to uuidv4. And SHA-1 hashes are 160 bits, vs. 128 for uuidv4.
But I love the idea of unrelated wolf attacks.
Speculation: The most likely scenario for a UUID v7 collision is if UUIDs are generated during a system boot sequence, before the system clock is set to the current time. It's always 1970 somewhere. There are still 62 random bits, and optionally another 12 random bits, but those too could be problematic if the system hasn't generated enough entropy yet.
I discussed some of the technical issues behind the article. If you disagree with anything I wrote, please say so.
I'm not even saying that the issues discussed in the article aren't useful, just going into how likely they're likely to be encountered in practice.
You can write a function declaration that's inconsistent with its definition in another translation unit. Declaring the function in a shared header file avoids this.
You can use an old-style declaration that doesn't specify what parameters a function expects. Don't do that. Use prototypes.
You can use a cast to convert a function pointer to an incompatible type, and call through the resulting pointer. Don't do that.
You can call a function with no visible declaration if your compiler overly permissive or is operating in pre-C99 mode. Don't do that.
"Atproto is a big-world open social protocol. Users publish JSON records into repositories. The changestreams of those records then sync across the network to drive applications."
It's too bad that information isn't on the front page. You have click "GET STARTED" and scroll down
"Whoever f---ed this up should be stabbed."
"I have excellent news for you."
I find it convenient not to have to worry about accidentally entering escape characters. YMMV.
Any law changing the name of the Defense Department would have to be passed by both Houses of Congress and signed by the President (or by 2/3 of both Houses overriding a Presidential veto). The Senate has no such authority on its own.
// Check whether a number is odd or even.
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
static bool is_odd_or_even(unsigned long num) {
return true;
}
int main(int argc, char **argv) {
const unsigned long num = strtoul(argv[1], NULL, 10);
printf("%lu is %s odd or even\n",
num,
is_odd_or_even(num) ? "is" : "is not");
}