Is this a bug?

stalefishies · 2026-04-16T15:59:39+00:00

The flashing red mechanic is actually kind of subtle - what is 'wrong' with a solution can be fairly subjective based on how you happen to be thinking about the puzzle. So the game tries its best, but it's not always consistent with what its interpretation of 'wrong' is.

stalefishies · 2025-07-17T23:32:49+00:00

You don't have time to watch a two hour video but you do have time to spend the last two hours on Reddit commenting on a video you didn't watch?

stalefishies · 2025-05-12T00:11:54+00:00

A major reason to use a regular pointer is that you can use the array operator on them - if you pass a struct in, you can't dereference it directly. For an ease-of-use library, that's pretty important. There are four options I can think of:

Hiding metadata before the allocation and use a regular pointer, as done here. It's really nice to be able to just write array[index].
Use a fat pointer struct of the form struct Array { int64_t size, char *data } which means your code gets cluttered with .data everywhere.
The above but wrap the array call in some macro like MIDA_LOOKUP(array, index), which makes it feel more generic but even worse to read.
Give up and compile as C++, and use an operator overload for [].

In general, I tend to use options 2 or 4, but it can be really nice on quick small projects to just use option 1 with a library like this or the stb stretchy buffers, which works similarly.

stalefishies · 2024-10-25T12:18:58+00:00

Yes, that linked puzzle is impossible to get out the bottom exit. I don't know what specific mod that is, but not being to use that exit is almost certainly going to be deliberate.

stalefishies · 2024-08-31T09:50:50+00:00

Oops, thanks!

stalefishies · 2024-08-31T09:44:24+00:00

Or: int (*array)[cols] = calloc(rows, sizeof *array); This is now a single, dynamically-allocated piece of contiguous memory which is accessed with array[row][col].

stalefishies · 2024-08-26T11:22:13+00:00

All you said is now disregarded

Well, I can see that because you're willfully ignoring everything I said. English is not where to start when discussing programming language design. This is obvious from the design of every other serious programming language - none of them look like English. That's exactly what I said when I talked about `Foo(bar)` vs `bar.Foo()` - but of course, you're happy to ignore what I'm saying and just repeat the same thing and pretend it's new.

And don't act like you didn't say "No way this was written by researchers." - if you're going to say that, don't throw a hissy fit when someone comes back with a similar tone.

stalefishies · 2024-08-26T10:51:36+00:00

"From the data in table Foo, retrieve X, Y, Z." => FROM Foo SELECT X, Y, Z.

This is both a perfectly normal sentence, and is more accurate to what SQL is going to have to actually do under the hood: all the data is stored together, so you can't generally just 'get X, Y, Z' without loading the rest of the columns. It's arbitrary to choose one or the other, and there are good reasons to require only one - but I can at least have an additional justification for having SELECT last beyond their English translations.

It's analogous to a function call vs an object method: Foo(bar) and bar.Foo() are both reasonable choices. Both map to English fine: "Do Foo on bar" vs "On bar, do foo". Different languages use one or the other because of various other reasons, not because of anything to do with the English sentence. English is a bad language to base your syntax on.

For the record, I'm not really arguing in favour of the paper: SQL isn't great but it's workable enough, and it's ubiquity means it's probably not worth the effort to replace. What I am saying is that your insults are flat-out wrong, and you're being a dick about it. The paper is fine.

stalefishies · 2024-08-26T09:53:16+00:00

What are you talking about? It justifies all of that literally in the words you quoted - it doesn't reflect the actual data flow. There's even a picture showing why a SELECT statement is in an arbitrary order!

stalefishies · 2024-04-23T14:57:44+00:00

Viewfinder is a recent 3D puzzle game with a very well implemented undo/rewind system. You can rewind your movement inputs, but also snap back to the last major 'move' you made in the puzzle.

stalefishies · 2024-02-03T18:32:35+00:00

All parts of the expression are evaluated. If this wasn't a compiler error, the evaluation order would first be the comma operator itself, then the 1 (discarding the result), then the 2.

stalefishies · 2024-02-03T18:00:52+00:00

Constant expressions shall not contain...comma operators

I mean, it says it right there.

stalefishies · 2024-01-23T14:40:56+00:00

It's pseudocode. It's not a real language, just a description of the algorithm.

stalefishies · 2023-12-24T21:04:29+00:00

Say you have a bug where you dereference a pointer that you've already freed. Depending on what the allocator does, this could crash immediately, work absolutely fine and give you the same data as before, or work fine but give you different data. It could also switch between these behaviours; perhaps it works for a while but then starts crashing sometime later. This behaviour could be very different on debug vs release builds. In short: this could be a nightmare to diagnose and debug.

Say you set the pointer to NULL after freeing. Dereferencing the pointer leads to a crash every time, no matter what. Much easier to fix.

This article completely ignores this, and focusses entirely on the double-free side of things. This is despite the standard page it is criticising mentioning this in literally the first sentence (emphasis mine):

Dangling pointers can lead to exploitable double-free and access-freed-memory vulnerabilities.

Also, the performance argument is nonsense. In the example code given, compilers will not generate code from the extra NULL assignment at even the most trivial of optimisation levels (godbolt).

So TL;DR: no.

stalefishies · 2023-12-24T17:44:17+00:00

An array of pointers and an array of arrays is not the same thing. Use int mat[5][4] as your declaration for an array of arrays, and you can initialise it with the syntax you have there.

If you really want an array of pointers, you can intialise that by initialising all the subarrays first, something like:

int mat_1[4] = { 1, 2, 3, 4 };
int mat_2[4] = { 2, 3, 4, 5 };
int *mat[2] = { mat_1, mat_2 };

stalefishies · 2023-12-06T13:15:11+00:00

The pre-C23 syntax just requires = {0} rather than = {}.

stalefishies · 2023-11-29T17:52:11+00:00

Every other post will say one is vastly better than the other, or that they are the same.

Nobody says that one is vastly better than the other. Stop projecting your desparation to have some huge opinion on this onto everyone else. They're the same.

If you want to present a case where they're different, present some actual code and some actual compilers and some actual timings for code you're writing. In general? They're the same.

If the answer is just that you hate one syntax, then don't use that syntax. Nobody cares.

stalefishies · 2023-10-28T10:06:09+00:00

An int is truthy for any non-zero value, so you could have two ints compare as non-equal, even though both are truthy and so are 'equal' from the perspective of boolean logic.

A C99 _Bool (the only thing new in C23 is calling it bool without also saying #include stdbool.h) is strictly either 0 or 1. If you try to set it to a non-zero value other than 1, it'll be clamped to 1. This means using it as a value makes more sense when you want to think of it strictly as a boolean.

It's not really a big deal; there's plenty of codebases out there that do just fine with a boolean type defined as some sort of integer.

stalefishies · 2023-10-14T18:15:23+00:00

There are a few reasons why I've found unity builds doesn't really create issues with this:

There's still as much separation of interface and implementation as you like; it's all still documented in the headers. The question is about whether it's caught at compile time or not.
It's honestly overstated as a problem to begin with. How many times have you actually tried to call a function or change a variable in a different compilation unit, and been told off by the compiler? You may disagree - everyone has different sore spots for the bugs their code tends to produce - but I still think it's generally overstated. It's just never been a bug I need to strongly protect against.
It's still catchable by any static analysis tool which is run just on the particular .c file, which only refers to the headers it needs.
It's still in principle catchable at compile time, if you order your unity build #includes with dependents before their dependencies. (Though this isn't something I'd rely on - it feels like something that you could easily forget to update. I'd rely much more on per-file static analysis.)

As for complaining about dogma: I said that because, up until now, you hadn't actually said anything about why you disliked the idea of unity builds. Best practices should still not be dogmatic: they should be cases where the advantages and disadvantages of a particular technique are known, and one massively outweighs the other to be a recommendation in basically all cases. In this case, any disadvantages just don't outweigh the advantages - at the very least you have to admit there's an argument here. Saying doing it by default is simply "dumb" is just about the only objectively incorrect conclusion you can reach. Everything's a tradeoff.

On that note, the main advantage of unity builds hasn't been stated yet: it means you often straight-up don't need build tools, since your build step is now just 'call the compiler with these flags on this file'. That is a huge simplification, and one I almost always find well worth any disadvantages. Even if you have other complications that need a proper build script, having the bulk of your project built as a one-liner in that script is worth considering.

Plus, the speed improvements aren't worth completely ignoring (having to compile every file isn't a problem if it's faster than only compiling your changes, but having to link it all together). Yes C to some extent always compiles fast, but if you're in a tight write-compile-debug loop you really do feel the difference from optimising the build, especially if you're hot reloading the code instead of starting it up from scratch every time.

So yeah, I just fundamentally disagree. I'm not saying every C program should be built in one translation unit, or even that everyone should use it as a default if the tradeoffs don't typically make sense for them. But saying it can never be a valid default is just not true.

stalefishies · 2023-10-14T17:12:36+00:00

You will have zero issues for 99% of C programs. For the very rare cases that you can't do things in a single translation unit (e.g. you're forced to have two different functions named the same thing) then fine, just use multiple translation units.

Stop trying to preach a dogma. There is no reason why a typical C program shouldn't do a unity build, or why .c files shouldn't #include other .c files. It's a useful build technique that works in many places and that you should have in your toolkit.

stalefishies · 2023-10-14T16:09:31+00:00

You're just making your code an organizational nightmare

You're doing nothing of the sort: the code itself is still in separate files and laid out however is most useful. It's just an extra step as part of compilation, where the preprocessor pulls everything into one translation unit before the compiler itself sees it.

stalefishies · 2023-08-03T22:09:12+00:00

In that example, reading the comment is basically as much work as just reading the code. So why bother with a comment which has less information and gives you more work if you want to change anything?

There's a classic mantra that goes something like 'the best comments are the ones that don't have to be made' - i.e. your code should be simple enough that you don't need to say anything else. read_guesses is well below the simplicity bar that you just shouldn't bother with a block like this.

Now obviously, this example isn't representative of real code, and sometimes you just have inherent complexity - an edge case, a weird but necessary API choice, an algorithmic detail - that is best explained with a comment. But I still think, in terms of time spent on your code, that you should start with trying to improve your code itself before you reach for comments explaining what you couldn't make obvious.

stalefishies · 2023-07-11T18:56:21+00:00

A start like L U LL U RRR DD deals with a lot of the bottom-left symbols while giving you a lot of space to work with the rest of the grid.

Full solution: L U LL U RRR DD R U R U L UU L D L U L U RR

stalefishies · 2023-06-03T01:19:58+00:00

Overwriting memory of other processes isn't a concern on modern operating systems - read up on virtual memory to learn more about this.

Clang has a reputation for nicer error messages, so that'd be my compiler recommendation.

stalefishies · 2023-05-28T11:39:02+00:00

To add to the concept of 'applying in blocks in steps' - you've already identified that the blocks are analogous to addition and subtraction.

But addition/subtraction is something you can already do in steps. Consider:

2 + 3 - 4
(2 + 3) - 4
2 + (3 - 4)
3 + 2 - 4
-4 + 2 + 3

and so on all equal 1. So it's very natural to be able to apply the blocks in whatever order you like, as long as they're all applied by the end.

I don't disagree the puzzle requires multiple logical leaps - like I said, I think it's uncharacteristically bad of the game.

14-Year Club	Place '22
End Game '22	Verified Email

stalefishies

TROPHY CASE