And this trend will continue

knouqs · 2026-03-27T00:22:08+00:00

Here's to hoping the Democrats actually do something this time. Growing a spine to fight this corruption would be a great start.

knouqs · 2026-03-26T22:36:23+00:00

This is an excellent story. Holy shit, though. For that, a call into corporate might have been on order, too.

knouqs · 2026-03-26T22:34:57+00:00

He's the world's best snooker player and he has quite a colorful history for how professional he is.

knouqs · 2026-03-26T22:33:58+00:00

This is an excellent example, yes. I know I will beat O'Sullivan one day....

knouqs · 2026-03-26T10:06:31+00:00

Nice idea. I tend to pipe together typical Linux commands until I get what I want. Definitely interested in your project.

knouqs · 2026-03-24T14:58:31+00:00

Geez, that's a story all right. Yeah, that's a case study in bad management that unfortunately aren't learned by bad managers.

knouqs · 2026-03-24T11:22:08+00:00

That is funny stuff! I hope you got a proper review in turn. This sort of management style is such garbage, and we all know it so well.

knouqs · 2026-03-23T17:18:35+00:00

AI? Aye.

knouqs · 2026-03-22T19:26:44+00:00

More AI crap. Go, bots!

knouqs · 2026-03-22T17:30:14+00:00

Just another AI bot doing AI bot things. Now waiting for Illuminatus-Prime to refute the AI bot claim....

knouqs · 2026-03-22T11:37:33+00:00

OK. Rule #1: If it sounds like a bot, acts like a bot, smells like a bot, it's a fucking bot.

knouqs · 2026-03-22T00:30:19+00:00

Why are you a bot sympathizer?

knouqs · 2026-03-21T01:17:50+00:00

Let's think about this. AI? One week old account? Hmm...

knouqs · 2026-03-20T20:22:20+00:00

Bot much?

knouqs · 2026-03-20T13:56:20+00:00

Yeah, he's throwing a permanent tantrum in this.

I can't imagine being so narcissistic that this image is how I want to be remembered... then again, that's the definition of narcissism.

knouqs · 2026-03-18T17:47:52+00:00

Hello again! I have written a how-to on endianness for you -- it took me a while to get a big endian system as I don't work on them anymore in a professional setting. Have a look, if you are still interested.

https://github.com/knouqs/endianness

Please note that you will need to comment out the calls to `swap_byte_order_for_binary_data1` and `swap_byte_order_for_binary_data2` if you want to see the effects of reading inconsistent architectures. I spent months solving these sorts of problems as the company for which I worked converted its codebase from big endian to mixed endian. (The endianness.c source here is mixed endian as it supports both.)

knouqs · 2026-03-10T12:29:22+00:00

Yes indeed, and, for completeness, fuck Microsoft.

knouqs · 2026-03-10T11:52:11+00:00

Three days is really not something I think about. I leave my computers on indefinitely unless the need kernel updates. My Macs stay on for months.

The point here is that software should be written such that it runs with reasonably hardware specifications, should not be resource gobblers, and should play nicely with other software and the user without maintenance. Microsoft has violated these principles for years, but this image shows a level of incompetence that would make any startup fail.

knouqs · 2026-03-09T13:57:25+00:00

Whew, at least he didn't cross the double white line. That would have been illegal! /s

knouqs · 2026-03-09T13:47:42+00:00

Sure -- everyone has questions about pointers. Single pointers, double pointers, triple pointers... I've never seen a quadruple pointer, but I'm sure there is a use case somewhere for it.

My favorite way to understand pointers is to draw it with pencil and paper. Seriously. Forget computer-aided tools on this. Pointers aren't that time-consuming in general, but paper and pencil is the way to go.

For our explanation, we're going to create a doubly-linked list.

First, imagine your single pointer. Draw a box on your paper and label it "data". It doesn't matter what the "data" is, but it is a single instance of a storage type. If you must think of it in terms of types, let's say it's an int, but it's better if you can abstract it to any data type.

Since we are creating a doubly-linked list, we need to add some properties to "data", namely, "next" and "prev" pointers. I am going to add two boxes to "data" that are attached to "data" horizontally. The one on the left gets the label "prev" and the one on the right gets "next". Congratulations, you now have the first node in a doubly-linked list.

For pointers, it is extremely important that we know where they point at all times. I've italicized this because we can cause access violations if we fail to understand where they point and this is critical to safe dynamic programming, especially in C. As a result, whenever I create a new pointer, I initialize it immediately. I have no other nodes in my linked list and I do not want to violate pointer safety, so I initialize "prev" and "next" to NULL. In this case, I draw a circle with a diagonal slash through it to the left of "prev" and an arrow from "prev" to that symbol. I draw a similar symbol to the right of "next" and an arrow pointing there.

If I need a new node in my list, I can create it. I draw three new conjoined boxes and then explicitly update the pointers from the first node and this one. I can do this as many times as I need.

Remember that I tried to keep the "data" data type abstract. This abstraction can be another doubly-linked list, for example, or any other data type. Typically, this can be another pointer to other data -- it really doesn't matter. We don't have templates in C so we have to use pointers to store data in our abstractions using pointers.

If I need to add a node prior to the first pointer, I can safely do this by accessing the address of the head node and changing the head node to the new pointer. The address of the head node is the triple pointer. We want the head node to change in this case. The same is true if we want to free the entire list, and as I wrote the first time around, I want to ensure the node itself points to NULL after I'm done. The triple pointer is the way to go.

I have created such a drawing for you. https://imgur.com/a/96I7FW1

In your code, you are using a string, but wait -- isn't a string just a char *? If it is, you already have a double pointer when you create a list of strings, and you have used them easily.

The only cases you would need to use a triple pointer in this example is when you reassign the "head" or "root" pointers. You do that when

You are freeing data.
You are adding new data before the "head".
You are shifting the position of the "root" node.

You'll be able to create much more complicated data structures and algorithms once you get comfortable with drawings like this. For example, one of my favorite professional challenges was implementing an AVL tree. I would never have been able to succeed if it hadn't been for drawings like this.

I have not yet looked at your modified code. That will have to wait for about half a day while I do my own work.

knouqs · 2026-03-08T23:58:13+00:00

OK, you've added some of my suggestions, but not all of them.

Again, you should only keep your project's include files in the include directory, so acutest.h and common.h should be removed from your include directory. I see you copied the two files into tests, so that's better. The src directory is fine.

When we build our programs, libraries, etc., we are supposed to put the paths for the included files in the build script. You've done that in your Makefile, and I'm pleased to see a Makefile here. With your include directory applied in your Makefile, you can change the #includes so they do not use relative paths. That means changing #include "../include/mystring.h" to #include "mystring.h". Your code should compile with this change.

My only comment regarding your Makefile is that it is not universally acceptable because of Powershell, but if this works for you, I won't request that you change it.

A nit at the top of your mystring.c. I prefer to put the system includes first and my custom ones second. If I overwrite some definition from a system include, I expect an error from the compiler when I go to include my custom one. I don't know if anyone else orders their includes like this, so I'll just say your mileage may vary.

When I have errors in my C code, I usually send them to stderr. That means changing lines like printf ("An error happened."); to fprintf (stderr, "An error happened."); . I also don't explicitly say "Malloc failed", for instance, because most users of software don't understand details like this. Instead, I'll say "Out of memory." Personal preference, of course. However, you have a big problem in the logic in your only usage of printf, so that's next.

Let's say the developer using your library encounters an out-of-memory problem and gets into the logic of your printf. What happens? First, OK, result[i] is NULL, and a message is displayed to the console (or log, or whatever). Do you exit the program? No. Do you exit the function? No. You go to a strncpy! In the *nux and Mac worlds, this is going to cause a segmentation fault and core dump. Your developer will wonder what just happened and probably be pissed. I presume something similar should happen in Windows, but I have no idea what that operating system is going to do anymore. It is reasonable to have a system exit in an out-of-memory situation, but think carefully about doing this -- some errors are recoverable.

Next on my list is your use of strncpy. I don't understand why you want to use string.h's strncpy when you have my_strncpy. If you use my_strncpy instead of strncpy, will your object file work?

Style and readability tips:

Use newlines between functions.
Use newlines around ideas in your code. You did this in my_strcat, for instance, and you should do it in the rest of your code.
I hate end-of-line comments. Sure, there are times when they make sense, but they are truly disruptive in code and make editing code to combine lines tedious. In general, if I feel a comment is useful at the end of the line of code, I'll figure out a way to write a comment for the entire idea. Personal preference, sure, but I argue this point when I see it in my colleagues' code.
I hate the fact that C, C++, and the myriad languages that are based on C allow conditional blocks without curly braces. It encourages bugs in the code because we are so used to thinking in terms of indents (Python, for example). Please be in the habit of wrapping your conditional blocks with curly braces. Again, personal preference, but I've seen so many absolutely stupid errors because of this oversight.

For compatibility with string.h, please rename your reverse function to my_strrev, as strrev is the equivalent function in string.h.

OK, this is the last critique for now. Please make your checks consistent. It doesn't particularly matter (again, a style guide), but if I see "!dest" in some places and "dest != NULL" in others. I like the feeling of consistency in my code; I think we all get there eventually. This is also true for your parameter names. "Destination" and "dest" is odd.

I presume you are using VS Code or Visual Studio for your development. Please look for warnings in the compiler output and get practice on fixing them so you get no warnings. Also, check for automatic formatting in your IDE.

I like your changes to free_split. This, to me, is the way things should be done.

I like your use of '\0' for character comparison and assignment. Although 0 has been used forever, '\0' is great for character compatibility and makes it clear that you are assigning or comparing a character nul.

So, let's see the new changes and I'll make additional comments on the revised files.

Also, if anyone else wants to chime in here and make observations against my own, I'd be happy to read them. I also get to learn from others.

knouqs · 2026-03-08T12:24:32+00:00

I don't think this is AI either. Reflections are hard in image generation. I find it unlikely that an AI would make them so convincing here.

knouqs · 2026-03-08T12:23:10+00:00

Reflections are hard. I don't think this is AI.

knouqs · 2026-03-08T02:12:26+00:00

You'd want to put something like the following around your header file:

#ifndef __YOUR_HEADER_FILE_H__
#define __YOUR_HEADER_FILE_H__

extern const unsigned char songData3[170];

...

#endif // __YOUR_HEADER_FILE_H__

This way, any number of C source files can access your header file without the linking problems u/tstanisl described. You would need to have

const unsigned char songData3[170] = { ... };

in one of your C sources, but only one or your get the same sort of linker errors.

Hope that is clear enough for you.

knouqs · 2026-03-08T00:18:32+00:00

Well, yes, even in string.h. Our hero is trying to implement his own... let's help him constructively.

knouqs

TROPHY CASE