141–150 of 163 posts
Earlier quoted context omitted.
And what does it mean there? (automatic storage duration)
It means it lives on the stack, so it "exists" until the function returns.
Earlier quoted context omitted.
That's allocated in a different segment.
It is now. Was it then? AFAICT from https://en.wikipedia.org/wiki/PDP-11 none of the PDP-X machines had a segmented architecture.
9.34.2 Assembler Directives
The PDP-11 version of as has a few machine dependent
assembler directives.
.bss
Switch to the bss section.
...Earlier quoted context omitted.
That period lasted what, 10 years after Unix was created? And we'll be stuck with those decisions decades if not centuries. Similar story with the design of QDOS / MS-DOS / Windows and nowadays with Android. Both designed for super underpowered machines that basically went away less than a decade after they were launched and that will be hobbled because of those early decisions for a long, long time.
We will be hobbled with these decisions for a long time precisely because the complete package of trade offs the designers made were so successful. If they had gone for wart-free on properly powered hardware, they would be stuck back in Multics land or living with the gnu Hurd—cancelled for being over budget or moving so slowly that projects that actually accomplish what the users need overtake them. Do I wish that C…
Earlier quoted context omitted.
Correct, return is not an expression. But then again, he could if he wanted to, as the language designer ;)
Wouldn't it be wonderful if we could write a = return b;
Earlier quoted context omitted.
Nice, I hadn't heard of this project before! In particular BOOTSTRA [1] looks really fun. I have also toyed with the idea of using MS-DOS 3.30 as a guaranteed-ubiquitous build environment. It comes with a filesystem, a text editor (EDLIN.EXE), an object file linker (yup!), a debugger/assembler (DEBUG.EXE is an amazing tool), a programming language with decent string handling (GWBASIC.EXE), and a command interpreter w…
I don't think that BOOTSTRA is in any way involved in the process bootrappable.org are working on, which starts with hex0 (the 512B machine code binary seed), proceeds through a ton of layers and eventually reaches non-interactive bash. https://github.com/fosslinux/live-bootstrap/blob/master/part...
Earlier quoted context omitted.
Nice, I hadn't heard of this project before! In particular BOOTSTRA [1] looks really fun. I have also toyed with the idea of using MS-DOS 3.30 as a guaranteed-ubiquitous build environment. It comes with a filesystem, a text editor (EDLIN.EXE), an object file linker (yup!), a debugger/assembler (DEBUG.EXE is an amazing tool), a programming language with decent string handling (GWBASIC.EXE), and a command interpreter w…
What is "guaranteed-ubiquitous" about DOS 3.30?
Those binaries will boot on anything from an ancient IBM PC with an 8088 CPU all the way through to fairly recent x86 systems (if they still have legacy BIOS boot support).
I have to say, the way indentation and brackets were done here looks like it's just inviting subtle bugs. Take this for example: if (peekc) { c = peekc; peekc = 0; } else if (eof) return(0); else c = getchar();
It would have made code review a nightmarish activity for the team.
So do I get this right: this is not the first C compiler (since that one would be written in B) and the first C compiler written in C?
Earlier quoted context omitted.
When not given a file, cat will just read from stdin, so you can use "cat > file.c", write some text, and send EOF with ^D when you're done. Obviously, there's no way to go back and edit anything mid-stream, you have to write the whole thing out in one shot.
The backspace does work within the line.
Earlier quoted context omitted.
And he was almost certainly using ed(1) as his editor and a mechanical teletype at 7.5 or 10.0 characters per second as his terminal... The C language (and all of Unix) was designed to be very terse as a consequence.
That period lasted what, 10 years after Unix was created? And we'll be stuck with those decisions decades if not centuries. Similar story with the design of QDOS / MS-DOS / Windows and nowadays with Android. Both designed for super underpowered machines that basically went away less than a decade after they were launched and that will be hobbled because of those early decisions for a long, long time.
Perhaps this is why a programmer would want to rewrite a system & tout "funny success stories" about the effort & results?
https://news.ycombinator.com/item?id=25844428
> Why couldn't you just upgrade the dependencies once then set up the same CI/CD you're presumably using for Svelte so that you can them upgrade versions easily?
Because the existing system was painful & time/energy intensive to upgrade. It happens with tight coupling, dependency hell, unchecked incidental complexity, architecture churn, leaky abstractions, etc...
Maintenance hell & > 1 month major version upgrades tend to occur with large, encompassing, first-mover frameworks, often built on a brittle set of abstractions, as they "mature" & "adapt" to the competition. e.g. Rails, Angular...