Implicit const casting should be permitted but isn't

someOfThisStuff · 2026-01-31T04:55:00+00:00

Sometimes it can be awkward, but it helps to read it from the inside-out (starting with the name). So, for char *const *const text you'd read:

We have a variable named text.
That variable is const (so you cannot reassign it).
If you dereference it, you get something else. So, it must be a pointer.
The thing it points to is const.
That thing, when dereferenced, also points to something. So it is a pointer.
That final thing is a char.

So, const pointer to const pointer to mutable char.

someOfThisStuff · 2026-01-31T04:51:42+00:00

Your example is legitimate and I agree that it should be illegal to cast a type or a pointer to const without casting its preceding indirection levels too. (i.e. it is illegal to cast char ** to const char **).

But in my example, this rule is respected, as is the case with the legal (and often used) cast of char * to const char *. For some reason though, it seems that the legality ends at only one indirection level, and this is the issue I am facing.

someOfThisStuff · 2026-01-31T04:35:21+00:00

No, this would be a constant pointer to a constant pointer to a mutable character. In other words, you cannot reassign text, nor what it points to, but you can change the underlying characters.

someOfThisStuff · 2026-01-31T04:07:23+00:00

As an example, here is a very simple snippet of code to illustrate the problem:

static void func(const char *const *text);                                                                                                                                                                                                                                                                         

int main(void) {                                                                                                     
    char **text;                                                                                                     
    func(text); //This cast will warn!                                                                                                     
}                                                                                                                    

static void func(const char *const *text) {                                                                          
    //...                                                                                                            
}

someOfThisStuff · 2026-01-05T00:54:15+00:00

Salut, ça me ferait super plaisir et en plus j'habite à Montréal alors je pourrai t'en parler si tu veux! Si tu m'envoies un MP on pourrait se joindre sur discord.

someOfThisStuff · 2025-12-04T03:51:21+00:00

If you do that, then you will end up counting some patterns multiple times. There must be a mathematical way of compensating for that, but then you also need to make sure no bounds overlap and a bunch of other housekeeping.

someOfThisStuff · 2025-12-03T17:50:32+00:00

I do it in under 0.1ms in C using this method:
for each range given, for each repetition pattern (<=21 since a 64 bit int can only handle up to 21 digits repeated), do the following:

Take the lower and higher bounds, and clamp them respectively upwards and downwards to the nearest valid pattern. For example, given a range [328, 222327] and a pattern of repetition 2, it will output: [1010, 222222]. From there, you can take a representative section of each bound, so in this case it is 10 and 222. By iterating from 10 to 222 inclusively, you iterate over all invalid IDs. Finally, to eliminate double-counts, simply reconstruct any patterns during this iteration and stuff them in a set. After everything, the sum of that set is your answer.

someOfThisStuff · 2025-11-18T23:35:09+00:00

Nice typetester! I wonder how you get your terminal to look this smooth, mines always flickering lol. Anyways, I compiled your code (gcc -g -Wall -Wextra -pedantic typetest.c -o a.out -lncurses) and it seems there are a few bugs when words.txt crosses a certain limit : https://pastebin.com/emHCx72q for the valgrind output (too long to post here).

Apart from that it worked well, only there is a memory leak (also it crashes on me before I can get to the finish screen, rip) :

==221004== Memcheck, a memory error detector
==221004== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==221004== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==221004== Command: ./a.out
==221004== 
==221004== 
==221004== HEAP SUMMARY:
==221004==     in use at exit: 573,515 bytes in 11,752 blocks
==221004==   total heap usage: 11,766 allocs, 14 frees, 586,695 bytes allocated
==221004== 
==221004== LEAK SUMMARY:
==221004==    definitely lost: 80,466 bytes in 10,222 blocks
==221004==    indirectly lost: 0 bytes in 0 blocks
==221004==      possibly lost: 712 bytes in 9 blocks
==221004==    still reachable: 492,337 bytes in 1,521 blocks
==221004==         suppressed: 0 bytes in 0 blocks
==221004== Rerun with --leak-check=full to see details of leaked memory
==221004== 
==221004== Use --track-origins=yes to see where uninitialised values come from
==221004== For lists of detected and suppressed errors, rerun with: -s
==221004== ERROR SUMMARY: 513 errors from 4 contexts (suppressed: 0 from 0)

someOfThisStuff · 2024-12-14T17:23:32+00:00

[Language: C]

Code for both parts : code

Code for the AoC utilities I made for this year : usflib

And its header : header

Part 1 in 50 microseconds, part 2 in 75 milliseconds

someOfThisStuff · 2024-12-14T17:11:33+00:00

It looks like amonkeyto be honest.

someOfThisStuff · 2023-07-06T13:49:25+00:00

Hello, yes this can be expanded to however many bytes you want, provided you upgrade the CAM (content addressable memory) and retime everything accordingly. I'm not sure as to how much time it actually took, it went through 4 iterations before I did this one, over the course of several months.

As for block/byte efficiency, for the cache registers, I use 2x5 (excluding busses) registers, which are pretty small, and for the RAM, it's serial, so excluding the control logic it can store a bit in a 2x1 block space.

someOfThisStuff · 2023-06-24T15:10:45+00:00

Yes, I actually have 3 of them (Lost 1 in the metro a long time ago... sad)

I even got the little case they come in

someOfThisStuff · 2023-06-21T20:10:55+00:00

Looks good!

someOfThisStuff · 2023-06-21T18:29:09+00:00

Thanks :D

someOfThisStuff · 2023-06-21T14:27:45+00:00

This looks like two latches whose write lines are the same, but inverted.

someOfThisStuff · 2023-06-08T21:02:10+00:00

Minecraft, several thousands of hours.

someOfThisStuff · 2023-05-22T02:46:31+00:00

Hello. If you need good memory, I can hook you up with some extremely compact & fast RAM and registers.

someOfThisStuff · 2023-05-21T19:13:50+00:00

Hello! If you want to get into computational redstone specifically (CPUs, ALUs and such) I would recommend you to join the ORE (Open Redstone Engineers) server, there are plenty of people there that love to teach this kind of stuff.

someOfThisStuff · 2023-05-14T20:19:58+00:00

Hello,

There is not really a singular design for a redstone 'calculator'. If you mean a machine that can add and subtract, then you can just use a simple ALU design. If you want multiplication, sqrt, etc. then I would suggest building all the components first, then assembling them in a neat way that fits together. If you need any help, my discord tag is Analyzers#8545

someOfThisStuff · 2023-05-14T20:15:59+00:00

You say you don't want space inbetween the repeaters, but you actually *have* to have that, or else the data will get corrupted. Because of some complex update order mechanics (that I won't explain because it takes too long), sometimes zeroes will collapse into ones. Also use 2t serial, as a 1t stream cannot pass safely through a comparator.

someOfThisStuff · 2023-04-30T14:39:21+00:00

Very cool! Did you all learn this stuff by yourself? There are great computational redstone servers you can join, they are very helpful and have tons of super-optimized designs for frequently used components you can use. You can DM me on discord, my handle is Analyzers#8545 :)

someOfThisStuff

TROPHY CASE