HN user

_kst_

2,293 karma

Keith.S.Thompson+hn@gmail.com

Posts0
Comments681
View on HN
No posts found.

Of course no sane person would spend ten years writing "All work and no play makes Jack a dull boy" over and over again". That wasn't the point.

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.

Strictly speaking it's the ISO C standard. ISO issues each new edition of the standard, and ANSI adopts it.

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.

No, the behavior is undefined. That means, quoting the ISO C standard, "behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this document imposes no requirements".

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.

Your code:

    int a = 5;
    int b = a++;
has well defined behavior. The first line initializes a to 5. The second initializes b to 5 and sets a to 6. (The language doesn't specify the order of the two operations of assigning a value to be and incrementing a, but in this case it doesn't matter.)

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.

"Test Your C Skills" is a published book by Yashavant Kanetkar, apparently published in 2005, and still available in paperback. The document you linked to appears to be a scan of a printed copy of that book, and is almost certainly in violation of copyright. The cover and the title and copyright pages are notably missing.

What can be optimized out depends on the context.

If you write:

    int i = 0;
    i = i++;
and never use the value of i, the declaration and assignment are likely to be optimized out. (The behavior of the assignment is undefined, so this is a valid choice).

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;".

Agreed.

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).

I don't see the name "thaumasiotes" at that link, nor do I see anything relevant to the code in the title.

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.

This reminds me of a passage from the book "Pro Git".

<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.

UUID v7 relies on knowing what time it is.

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.

It's not even possible to pass too few arguments to a function in C unless you go out of your way to write bad code.

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.

The summary of what this is about is:

"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

SSH Secret Menu 4 months ago

That doesn't do much good if you set `EscapeChar` to `none` in `.ssh/config`.

I find it convenient not to have to worry about accidentally entering escape characters. YMMV.

The author missed an opportunity for a much shorter solution for the given problem statement.

    // 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");
    }
Dependable C 7 months ago

I see a huge semantic gap between assembly language and C.

An assembly language program specifies a sequence of CPU instructions. The mapping between lines of code and generated instructions is one-to-one, or nearly so.

A C program specifies run-time behavior, without regard to what CPU instructions might be used to achieve that.

C is at a lower level than a lot of other languages, but it's not an assembly language.

Are you sure it's been open sourced? I'm reasonably sure you've linked to a site offering pirated copies.

There are several links to PDF versions of the book. None of them include either a copyright page or a statement that it's been released as open source.

The author's own website <https://afu.com/> includes errata for the book, but doesn't provide or mention a free copy.

A free sample of the Kindle version of the book does include a copyright notice. A book published in 1994 is not public domain unless it's been explicitly released.

Something that appears to be a legitimate PDF sample (not the while book) is here:

https://ptgmedia.pearsoncmg.com/images/9780131774292/samplep...