HNHacker News
TopNewBestAskShowJobs

_kst_

2,297 karma · joined March 20, 2012

Keith.S.Thompson+hn@gmail.com
submissionscomments
_kst_··on 4 billion if statements (2023)
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");
    }
_kst_··on Dependable C
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.

_kst_··on The Pragmatic Programmer: 20th Anniversary Edition (2023)
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...

_kst_··on Fire destroys S. Korean government's cloud storage system, no backups available
I think you meant to post this comment here: https://news.ycombinator.com/item?id=45481892
_kst_··on We shouldn't have needed lockfiles
OK, but to me a "lockfile" is a file whose existence signals that some resource is locked.

https://en.wikipedia.org/wiki/File_locking#Lock_files

When I saw the title "We shouldn't have needed lockfiles", I expected something about preferring some other mechanism for resource locking.

More generally, I see a lot of articles that talk about an issue in some language or framework that don't mention that context. Just adding "JavaScript" or "NPM" (or whatever) in the title or near the top of the article would be very helpful.

_kst_··on We shouldn't have needed lockfiles
The author seems to have assumed that readers are going to know that he's talking about NPM and JavaScript, and that "lockfiles" are an NPM-specific feature (to me, it means something completely different).

Perhaps that's a valid assumption for readers of his blog, but once it appears here there are going to be a lot of readers who don't have the context to know what it's about.

Can an "NPM" tag be added to the subject of this post? More generally, I encourage authors to include a bit more context at the top of an article.

_kst_··on Replacing tmux in my dev workflow
I use Ctrl-Space.

    unbind-key C-b
    set -g prefix C-Space
    bind-key C-Space send-prefix
I find it a lot easier to type than either Ctrl-A or Ctrl-B.
_kst_··on Programmers aren’t so humble anymore, maybe because nobody codes in Perl
Not officially, but there are a couple of retronyms.

Larry Wall originally wanted to call it "Pearl", but found there was already a language by that name, so he shortened it to "Perl".

The name is sometimes expanded as "Practical Extraction and Report Language", or as "Pathologically Eclectic Rubbish Lister" (Larry Wall's own phrase, mentioned in the Perl man page).

But yes, "Perl", not "PERL", is the correct name for the language.

(Ada, which was named after a person, has had the same problem, though as far as I know there isn't even a retronym for Ada.)

_kst_··on Phrase origin: Why do we "call" functions?
Algol 60 also uses the word "call" for parameters as well as functions. It introduced (?) the terms "call by value" and "call by name". For example, in 4.7.5.3: "In addition if the formal parameter is called by value the local array created during the call will have the same. subscript bounds as the actual array."

In modern terminology, we call procedures/functions/subroutines and pass arguments/parameters, so "pass by (value|name|reference)" is clearer than "call by (value|name|reference)". But the old terms "call by value" et al have survived in some contexts, though the idea of "calling" an argument or parameter has not.

_kst_··on Corrected UTF-8 (2022)
"If this standard is accepted, if no magic number you have corrected UTF-8."

That's true only if "corrected UTF-8" is accepted and existing UTF-8 becomes obsolete. That can't happen. There's too much existing UTF-8 text that will never be translated to a newer standard.

_kst_··on Corrected UTF-8 (2022)
"UTF-16 is now obsolete."? That's news to me.

I wish it were true, but it's not.

_kst_··on U.S. bombs Iranian nuclear sites
The last US declaration of war was in 1942, against Hungary, Bulgaria, and Romania (allies of Nazi Germany).
_kst_··on Hacktical C: practical hacker's guide to the C programming language
C is a relatively low level language, but it is not assembly language.

The difference is clear. Assembly language programs specify sequences of CPU instructions. C programs specify runtime behavior.

_kst_··on Make C string literals const?
Sure if the new binary is bitwise identical to the old one, there's no need to release it.

But ...

"The era of reproducible builds is upon us"

What about old code built with old toolchains? And what about organizational policies that require a full round of testing for any update? How hard do you think it would be to change such policies?

No doubt there's some software that could easily be modified, recompiled, and released. My point is that there is also some software that can't.

And yes, in those cases the likely solution is to leave the code alone and continue to build it with the old toolchain.

The point is that the proposed change will break existing valid code, and that has a non-zero cost. I support Jens Gustedt's effort to find out just what that cost is before imposing the change. (And again, I hope the change does go into the next edition of the standard.)

_kst_··on Make C string literals const?
My point is that the risk of breaking existing code is the only reason not to apply this change to the standard.

My point is also that that's a valid reason to proceed carefully before making the change.

Even if the required source code changes are trivial or automatable, there will still be some variable amount of work required to deploy the changes. For a small program or library, maybe you can just rebuild and deploy. But for some projects, any change requires going through a full round of review, testing, recertification, and so on. For an update to code that controls a medical device or a nuclear reactor, for example, changing the code is the easy part.

I support the proposed change. I also support performing all due diligence before imposing it on all future implementations and C software.

_kst_··on Make C string literals const?
A conforming implementation could make string literals modifiable, and (obviously non-portable) code could rely on that. I don't know whether any current compilers do so. I suspect not.

Apart from that, it's not about actually modifying string literals. It's about currently valid (but admittedly sloppy) code that uses a non-const pointer to point to a string literal. It's easy to write such code in a way that a modern conforming C compiler will not warn about.

That kind of code is the reason that this proposed change is not just an obvious no-brainer, and the author is doing research to find out how much of an issue it really is.

As it happens, I think that the next C standard should make string literals const. Any code that depends on the current behavior can still be compiled with C23 or earlier compilers, or with a non-conforming option, or by ignoring non-fatal warnings. And of course any such code can be fixed, but that's not necessarily trivial; making the source code changes can be a very small part of the process.

Any change that can break existing valid code should be approached with caution to determine whether it's worth the cost. And if the answer is yes, that's great.

_kst_··on Make C string literals const?
The C standard, since 1989, has said that attempting to modify the array object corresponding to a string literal has undefined behavior. Whether it "works" or not is not the issue.

The problem is that it's currently legal to pass a string literal to a function expecting a (non-const) pointer-to-char argument. As long as the function doesn't try to write through the pointer, there's no undefined behavior. (If the function does try to write through the pointer, the behavior is undefined, but no compile-time diagnostic is required.) If a future version of C made string literals const, such a program would become invalid (a constraint violation requiring a diagnostic). Such code was common in pre-ANSI C, before const was introduced to the language.

The following is currently valid C. The corresponding C++ code would be invalid. The proposal would make it invalid in C, with the cost of breaking some existing code, and the advantage of catching certain errors at compile time.

    #include <stdio.h>

    void print_message(char *message) {
        puts(message);
        // *message = '\0'; // would have undefined behavior
    }

    int main(void) {
        print_message("hello");
    }
_kst_··on SpaceX's Fram2 returns from first-of-its-kind mission around Earth's poles
Different crew vehicles have different capabilities. Dragon is similar to Soyuz, Apollo, et al. It doesn't have a lot of maneuverability on the way down -- and if it lands in the ocean, it doesn't need it. (Soyuz lands on land; again, if it's off target it's no big deal.)

I think there were designs for a version of Dragon that could do propulsive landings, but that was abandoned.

Assuming they get Starship working reliably, it will do precise landings, probably with a tower catch, eventually with a crew on board.

_kst_··on James Webb Space Telescope reveals that most galaxies rotate clockwise
The study is based on 263 galaxies.

It should be fairly easy to determine the rotation direction of any (spiral) galaxy we can see, based on reasonable assumptions about the relationship between rotation and the configuration of the spiral arms. There should be thousands or millions of visible galaxies for which this could be determined (out of the estimated 2 trillion galaxies in the observable universe). Perhaps I'm missing something, but why bother reporting a result from such a tiny sample?

It should also be possible to derive more detailed information that just clockwise vs. counter-clockwise. The rotation of a galaxy defines a direction (the galaxy's rotational north pole) and a point on the surface of an imaginary sphere. This could be determined by the galaxy's apparent rotational direction, its orientation, and its position in the sky. It would be interesting to see a plot of those points. In principle, they should be random. (If the points spell out "Go stick your head in a pig", I'll be very sorry that Douglas Adams didn't live to see it.)

_kst_··on The Defer Technical Specification: It Is Time
The author is the project editor for the ISO C standard.

(And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)

_kst_··on Magpies and crows are using “anti-bird spikes” to make nests (2023)
Reminds me of the rats we used to have in our garage, that had built nests from our dryer lint.

Our dryer lint was largely cat hair.

_kst_··on Magpies and crows are using “anti-bird spikes” to make nests (2023)
Mounted on a coconut.
_kst_··on GitHub reveals how software engineers are purging federal databases
I deal with the main/master brouhaha by using a script I wrote that determines the name of the appropriate branch:

    #!/bin/bash
    
    git remote show origin | sed -n '/^ *HEAD branch: */s///p'
It's in my `$HOME/bin` as `git-master`, symlinked as `git-main`.

    git switch $(git master)
(`git foo` finds and executes a `git-foo` command anywhere in $PATH, a handy feature if you want to implement your own extensions.)

(This is of course irrelevant to the topic of the top-level post.)

_kst_··on Seconds Since the Epoch
Apparently both Pelles C for Windows and VAX/VMS use a 32-bit unsigned time_t.
_kst_··on Seconds Since the Epoch
Leap seconds should be replaced by large rockets mounted on the equator. Adjust the planet, not the clock.
_kst_··on Seconds Since the Epoch
Neither C nor POSIX requires time_t to be signed.

The Open Group Base Specifications Issue 7, 2018 edition says that "time_t shall be an integer type". Issue 8, 2024 edition says "time_t shall be an integer type with a width of at least 64 bits".

C merely says that time_t is a "real type capable of representing times". A "real type", as C defines the term, can be either integer or floating-point. It doesn't specify how time_t represents times; for example, a conforming implementation could represent 2024-12-27 02:17:31 UTC as 0x20241227021731.

It's been suggested that time_t should be unsigned so a 32-bit integer can represent times after 2038 (at the cost of not being able to represent times before 1970). Fortunately this did not catch on, and with the current POSIX requiring 64 bits, it wouldn't make much sense.

But the relevant standards don't forbid an unsigned time_t.

_kst_··on "Rules" that terminal programs follow
> 1. Don’t assume a terminal type. Look at `TERM` and use termcap/terminfo or a library built atop them for anything beyond line-oriented plain text output, or least assume a plain teletype unless you specifically recognize the user’s terminal type.

I agree, but these days I think you can mostly get away with assuming VT100-compatible behavior.

> 4. Use the standard `<sysexits.h>` exit codes. They exist for a reason and they make use of your tool within pipelines and programs more straightforward because they make it easier to trace why a failure occurred.

I just took a look at this header file. (It defines exit codes starting at 64.) I'm not sure I've ever seen a program that uses these codes. Many programs for UNIX-like systems just use exit(1) for generic errors, or maybe something to distinguish between data errors and usage errors such as unrecognized command-line options. I mostly use Linux; maybe it's more common on BSD-based systems (it appeared "somewhere after 4.3BSD"). For example curl defines nearly 100 distinct error codes; none of them are based on <sysexit.h>.

> 5. Include both in-binary `--help`/usage information and a man page. Often a user will just need a quick refresher on argument syntax, which is what the built-in help text is for; the man page should be a comprehensive reference with examples. It should never defer to a web page or GNU `info`—it’s fine if those exist too and are pointed out, but they should not be the primary user reference.

In practice, GNU `info` tends to be the primary reference for GNU programs. The man page is often missing a lot of information.

_kst_··on "Rules" that terminal programs follow
You can (usually) run your remote tmux in a window in your local tmux session; then you can use the local tmux session's copy/paste features.

I commonly run "ssh remote-system" in a tmux window, then attach to a tmux session on the remote system.

If you nest tmux sessions like this, you have to type the prefix character (Ctrl-B by default; I use Ctrl-Space) twice for the nested session to see it.

_kst_··on "Rules" that terminal programs follow
> Don't use color as the only indication of something. The user's terminal might not display it, and it probably won't be preserved in copy&paste into notes.

And some of us choose to disable color by default. (Yes, I'm old-fashioned.)

_kst_··on Qutebrowser: A keyboard-driven, Vim-like browser
I got the same thing and worked around it by installing the previous release.
← PreviousPage 2 of 23Next →