I'm already running tmux. Opening a new window is easy.
2,308 karma · joined March 20, 2012
// 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");
}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.
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...
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.
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.
unbind-key C-b
set -g prefix C-Space
bind-key C-Space send-prefix
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.)
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.
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.
I wish it were true, but it's not.
The difference is clear. Assembly language programs specify sequences of CPU instructions. C programs specify runtime behavior.
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.)
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.
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.
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");
}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.
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.)
(And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)
Our dryer lint was largely cat hair.
#!/bin/bash
git remote show origin | sed -n '/^ *HEAD branch: */s///p'
git switch $(git master)
(This is of course irrelevant to the topic of the top-level post.)
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.
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.
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.