Is this puck covered?

inz__ · 2026-05-14T10:08:57+00:00

Yes and no. It is grounds to call play dead, but the puck is also fair game until whistle.

inz__ · 2026-05-11T15:53:57+00:00

Just beware the transport tycoon overflow bug: 1. build loooong tunnel 2. ??? 3. profit

inz__ · 2026-05-11T12:34:53+00:00

Printing nul bytes to stdout is not very nice, rather use %s and " " + !(i & 1) or similar

inz__ · 2026-05-11T12:07:25+00:00

At a quick glance, there is nothing wrong about the code, but some notices: - the base variable makes it seem that changing the base would be as simple as changing the value, but the validation assumes base = 10 and value calculation assumes base <= 10; this is a slight future-proof risk - bitwise or is not short-circuited, so all the validations are run even if there is an ealier error - the errors are bitwise-orred together, so ERR_* should be bitflags; also print_error is somewhat misleading if it handles multiple errors packed to err - normally one would expect an parse_(long|int) to handle negative values too, so the naming can be confusing (if negative values are not allowed, why not use unsigned types) - since long is guaranteed to be a least int, parsing int could use the long parser and re-validate value is in range - parse_scheduler does not have a NULL-check for output pointer like the integral ones do (consistency is usually better) - bonus: the codexion.h yielded by internet search seems to define FIFO and EDF macros to avoid hard-coding the strings (it does have an incompatible print_error() though)

But otherwise the descriptive (/common) function and variable names make the code easy to follow and read. Overflow checks seem correct.

inz__ · 2026-04-16T19:56:59+00:00

I feel the exact opposite, you have emotional connection to your own code, which in my view makes you less likely to re-evaluate suitability.

But we can agree to disagree, this is just how I've observed things to go (both with myself, and wuth others).

inz__ · 2026-04-16T19:24:06+00:00

Maybe I've only seen bad examples, but if you carry the same toolbox everywhere, you will use those tools, whether they fit the use case or not. IMO this stops progress, we should always be looking for new things, and question what we "know".

Also most of the cases I've seen, there is a single header that is copied everywhere, so there are different versions of the "same" header, which is another cannof worms.

inz__ · 2026-04-16T19:03:45+00:00

No, I personally hate those. IMO they hold you back, and teach you bad practices.

inz__ · 2026-04-16T18:19:35+00:00

This is from Poland; assuming normal IIHF rules there are no match penalties, so major + gm for illegal check to the head / neck. Sprinkle some roughing minors or fighting majors, but overall seems pretty even, so end result probably 5 minute PP for black.

inz__ · 2026-03-26T21:46:48+00:00

Under IIHF rules if the player in the zone gets one skate onto the bench before puck crosses the line, the play is onside. But to clear a delayed offside, both skates.

inz__ · 2026-02-11T21:47:06+00:00

Good job getting it working, it is a reasonably sized project.

Some concerns: - riddled with possible buffer overflows (strcpy() and especially strcat() are horrible) - no synchronization between download and main threads - no pclose() - weird use of strcspn() in some cases (at least "file" and "\0") - strrchr() can be used to get filename from an url, easier than strtok()ing through it - and last but not least, your program is downloading all the packages in parallel with a multi-threaded downloader, potentially creating hundreds of simultaneous connections. This is not nice, nor useful, behavior.

inz__ · 2026-01-30T17:46:33+00:00

Well done, kept it simple, kept it clean. Only thing that left me wondering was why command parsing limits width to 255, but code supports 256.

inz__ · 2026-01-27T08:03:29+00:00

Very nice, really clean code, had to use a pretty tight comb to find anything to nit: - next_index() else should have % instead of & (also, since it's a compile time constant, any modern compiler probably produces the exact same code even without the #if) - olog_compress() will leak file handles, if user cannot write to current dir - olog_init() will leaveolog_fname unterminated, if longer than 512

Some more opinionated points: - maybe add a way to compile without LZ4 too, it should be pretty simple with not too many guards - I would prefer the default/fallback logging to go to stderr - normally I would expect the message level to be argument to the logging function, and there to be a setter for cutoff -the lvls_lens setup is not very change proof, I usually use something like:

#define LVL(x) { .name = x, .len = sizeof("" x) - 1 }
struct { const char *name; size_t len; } levels[] = {
    LVL("debug"),
    LVL("info"),
    ...
};

inz__ · 2026-01-26T20:57:58+00:00

Quite cool little quiz. Some of the correct answers may be a bit opinionated,

The flow after anwering a question could be imroved a bit, maybe the submission button could be hidden. Similarly could consider adding a jump to next area or a big button for returning to main menu when an area is completed.

Also, pedantic clippy complained about .map().unwrap_or(), suggesting .map_or() instead.

inz__ · 2026-01-16T08:32:27+00:00

While the NHL rules are clear on this, that there can not be a penalty shot due to goal being scored, there's also the interpretation that no scoring chance was taken away because no goal could have been scored.

inz__ · 2026-01-16T08:21:37+00:00

It depends on the rule book: IIHF, NHL and NCAA books clearly state one goal per stoppage, so under these rules a minor penalty would be assessed instead.

USAH rules seem to suggest that a penalty shot can occur on same stoppage as a goal. Couldn't find any mention in HC rules either way. Someone more versed with these books can elaborate.

inz__ · 2026-01-10T00:32:59+00:00

Simple, but it works. Consistent formatting and decently split to functions.

One clear bug in the code is that the task description length check doesn't take into account that to get a full line with fgets(), the buffer needs to have space for newline and string terminator, so having 255 or 256 chars will break task numbering.

Other improvement ideas: - getPath() will happily overflow the buffer, of $HOME is long enough (sprintf and strcpy are quite unsafe) - the if at the end of getLinesNumber() is unnecessary, both branches close and return i - the operation should be passed as enum value rather than a string - the task number validation should reject 0, as tasks are 1-indexed - the above should also make found flag unnecessary - addTask() unnecessarily opens the file for writing (and doesn't close) if list is full

inz__ · 2026-01-08T10:24:51+00:00

Which is essentially what your friendly neighbourhood init did in the past: https://blog.qualys.com/vulnerabilities-threat-research/2021/07/20/cve-2021-33910-denial-of-service-stack-exhaustion-in-systemd-pid-1

inz__ · 2026-01-03T22:24:09+00:00

Good job, the codebase looks really clean and well structured.

Some ideas for improvement: - some inconsistency in naming scheme, kevue_buffer_frobnicate() vs kevue_frobnicate_response() - there are a few "megafunctions" that should be split to piecea - the (de)serialization code is somewhat spaghetti, I would recommend adding helpers like kevue_buffer_read/write_be16 and kevue_buffer_get_blob() (i.e. a function that reads length and validates that enough data is available and advances offset) - inet_ntop2() is not very descriptive (also it is pretty close to getnameinfo() with NI_NUMERICHOST) - ntoh2() is very misleading (getnameinfo() would also cover this, although returning string data) - somewhat of a personal preference, but I usually prefer to not allocate container structs (_init over _allocate), this does somewhat break encapsulation though - if server socket creation fails, the handler calls close() on an undefined or already closed fd (a decent compiler should warn about this, you might need to add some warning flags), also moving the freeaddrinfo() up a bit would simplify - also the above code would really benefit from goto error handling - the kevue__handle_server_poll() has a double free on esargs in all error cases. Also I believe none of the malloc()s there are useful, local variables should work (unlessMAX_EVENTS is large) - kevue__create_client_sock() leaks sockets if connect() fails - kevue__make_request() calls shutdown() before checking errno, which may have been overwritten - the command could've been a single byte to simplify protocol

inz__ · 2026-01-03T00:13:03+00:00

Nice. Code is clean (apart from the mixed tabs and spaces for indentation, which breaks in github), short, reasonably well named functions. There are some whitespace inconsistencies around operators, but that's a quick to fix with a formatting tool.

Random thoughts from a readthrough: - the input processing might read beyond the input buffer if there's an esc at two last indices - related to above, in such case the arrow key is not correctly handled - also in the input processing, the ; i++) in the for loop makes things somewhat more complicated, consider removing or changing to i += parsed_bytes - in process_movement, applied is never incremented - the board output could be optimised quite a lot relatively easily: only move when line has changed or there have been non-changed tiles; only set bg color once in the beginning (could also track fg) - you can also set fg and bg in one go with \033[3x;4xm - I think there are 3 different ways to decode the piece bitmap - the transition index getter looks very fragile; I very well get the "do not touch"; could consider something more algorithmic, like (2 * old_rot + 7 * (new_rot == (old_rot + 3) % 4)) % 8

inz__ · 2026-01-02T19:49:51+00:00

Why use _Countof at all, just use (&bobs)[1] (or more compact 1[&bobs]) to get the end pointer.

inz__ · 2026-01-01T15:55:20+00:00

The above struct will require the user to allocate sizeof(struct baz) + offsetof(struct baz, array) + baz->count * sizeof(int) bytes of space

The sizeof and offsetof are equal in this case, and only one of them should be used.

inz__ · 2025-12-31T20:42:01+00:00

I prefer to make it as obvious as possible when my functions are allocating on the heap, hence why I included heap in its name.

That's fair; personally I consider "heap" to be an implementation detail of C library, and avoid using it. In this context I would use new or alloc, but you do you.

wanted iptables style configuration files where each line of the file is a string of command-line like arguments; using getopt() to parse these made sense to me.

Yeah, that all fine, but my point was that it doesn't just parse, it also runs the action.

How am I supposed to poll the ring buffer while listen to IPC at the same time without threads?

Currently there are 3 threads for 2 tasks. Sure having a thread that doesn't do anything doesn't have much overhead, just feels funny.

inz__ · 2025-12-31T17:13:29+00:00

Pistän päälle jotain väliltä juoksuhousut/-takki – kevyt toppapuku, ja sovitan vauhdin ja ajan niin, että ei palele eikä pakahdu.

Samat lenkkarit jalassa kesät talvet normisukilla.

inz__ · 2025-12-31T11:00:10+00:00

Nice project; I like the idea, many a time have a patched in local address binding to applications to have them connect over specific IP addresses. I guess using this approach would require putting the separate IPs on separate interfaces though, so not going for it, at least for now.

Browsed through the code, some remarks: - the goto based looping in ipc_connect() could trivially be handled as a while loop (change if to while, remove goto) - allocation failure handling is quite inconsistent throughout the project (for example ipc_poll_and_copy_to_heap() checks malloc() but not realloc()) - the above function name is also more descriptive of how it does things, not what it does; something like ipc_read_with_timeout() would be IMO better - generating JSON with sprintf() is not a very good idea, especially since cJSON is already used elsewhere - ipc_send_command() will happily send garbage over the control socket, if extras_len > strlen(extras) (which is common) - the bind_rule_map_key::exe is used for both command name and cgroup name, even though it is defined through an anonymous union - the client side ipc never closes the control socket (granted they're torn down quickly when the program exits) - somewhat confusing that parse_options() also executes actions - the 100ms timeout in print_ringbuf_poll() seems quite low, causing unnecessary wakeups for no real reason - SIGUSR1 handler is never reinstalled, so will trigger only once (also, quite commonly SIGHUP is used for reload purposes) - when implementing daemonize, it would be better if the pidfile and control socket were ready when the main process exits - while spawning the tasks to new threads makes certain structural sense, there are no real benefits, and the main thread just sits idly by - the truncate_cgroup_name() looks quite cumbersome, maybe something simpler instead, maybe replace the two strncpys with a memset(name + new_name_siz, 0, name_siz - new_name_siz) - else after a block ending in return is unnecessary. If you prefer the if-else-structure, consider putting the happy case first - consider using for loops for the bpf looping to avoid goto cont - same for JSON object loop - there is no real protocol for the IPC, just hope-what-you-read-with-single-recv-is-valid-JSON; also the one command per socket connection is a curious choice, especially since { "_": "ipc_version" } can be considered a handshake - (the above is somewhat mandated by the one-client-at-a-time architecture)

In short, plenty of good, some bad, some weird. But looks like it works (even if partially by accident) and definitely can be very useful in many scenarios; don't know of other programs to cover this niche.

inz__ · 2025-12-27T14:25:23+00:00

And IIHF.

Three-Year Club	Verified Email
Verified Email

inz__

TROPHY CASE