It's more satisfying than ever to see people still questioning prevalent assumptions and critically reassessing the fundamentals. Lately, I've been writing a lot of DSP code in C, and that has certainly proven a valuable exercise for much the same reasons you demonstrate here.

...With the added fun of dealing with numerical stability, of course.

Thank you so much!

Impressive work and an interesting write-up. Kudos!

    size_t* prev = malloc((m + 1) * sizeof(*prev));
    size_t* cur = malloc((m + 1) * sizeof(*cur));

I'm in awe that a beginner thought of levenshtein's distance upfront and made room for it. Top work. But then a common beginner mistake is to assume everything is on Heap or everything is on stack. You could make an approximate guess on how many characters deep you want to go finding difference, allocate that up front (something like [256]) and restrict your search diff within that.

But overall, its good work. Was able to compile it hassle free.

If you feel like playing around, consider trying my Make fragment from this comment. See if it helps pick some bugs early on in development.

AGPL 3.0 is best to fight enshittification.

Hi,nice that you go in kernel dev,D.eSystem itself is not suporting apps or something from outside,but you can go on the github link,download the source code andadd own features to the kernel and you can compile D.eSystem:)

hey, I started going into kernel dev recently and found it real interresting, even made my own miniature kernel in C and arm :).Is there a possibility to contribute something small to your kernel? would love to learn more things about that.

Never done this, so did some research. Hope this helps put you on the right track!

https://stackoverflow.com/questions/526430/c-programming-how-can-i-program-for-unicode

https://www.cprogramming.com/tutorial/unicode.html

You could use GLib which has a gunichar type and a bunch of functions for operating on them

This is why I am asking here - the objections are not only with Codeberg - I will probabley maintain my own git instance (once I learn how) but I am asking programmers at large. Codeberg has it's policy - and that policy was driven by some of the programmers there. so I am asking programmers, not codeberg.

Why are you asking here and not Codeberg then? Nobody can answer for them.

There's no way you're going to be able to train an LLM from scratch without a giant corpus of real code and English text. Even if you managed to procure that ethically, it would only address one of a number of objections people have to these things.

Codeberg just went fully AI adverse. I am a retired guy and I don't want to spend the time to code every jot and tittle of a big project - I wrote my own basic interpreter (I specified, claude wrote) If I did not have the AI help I would be years doing this - I may not have years.

So by permissible I am talking about an AI that can generate code to spec that is free of copywrite objections.

You would end up with this if you had no sample code: https://en.wikipedia.org/wiki/Duff%27s_device

Anyway, permissible for what?

And btw,I started developing D.eSystem 6 on Windows on my main PC which have a Ryzen 7 5800x and a RTX 3060 12gb,but then I tried Linux mint on an Laptop which I just had Laying around,the Laptop is a Medion Akoya e7218 and I used it a loot and as a seccondary Linux device to my main Laptop which is a thinkpad,then I installed Linux Mint on a dell optiplex 3000 SFF as a Linux desktop for Programming and OS development.

Thanks

I hate that these days I have to go dig through people's history to see whether something is slop or whether I should upvote it, but I'm delighted to say it appears this project doesn't use LLMs. Cheers, OP.

Hey man, I remember when you first posted about your OS. Glad to see you're sticking with it

Thats a nice idea,thanks for your comment

I had this idea for a while that I wanted an OS that lets the user have the ability to build their own folder system framework. I moved to linux from windows a year or two ago and the linux file system structure is still the bane of my existence. Which even tho was one of the least obnoxious part of the obnoxious windows file expolere but only because how obnoxious everything windows touched was.

I'll attempt to give a more hand wavey approach, but one that is hopefully easier to understand.

First, implement:

\\ find first index of `c` within string `str`.
\\ returns true if found, sets `out` to result.
\\ otherwise returns false.
bool find(char* str, size_t len, char c, size_t* out)

Now this can be used in a loop, where you supply a slice starting at the last line (or the beginning of the slice, on the first iteration), where len is the length of the original string minus the amount of characters consumed (index of the beginning of the slice, relative to the start of the original string).

Note this requires calculating the string length beforehand, if this is a c-string (as in null terminated).

This should be relatively simpler to understand and implement than what the standard library supplies, sadly the C standard library is not easy to use or very reliable, so you'll mostly have to make do yourself.

I hope this helped, I'm currently away from a computer so i can't give a code example, good luck.

TBF it is not complicated but it does use the simplest form of pointer arithmetic and order of operation of (++var) or (*var++). Considering OP couldn't write a basic version of this I did not want to put pressure on him. If you can understand it as a beginner good for you! You must remember that a lot of developers struggle to learn pointers in the first place for some reason. I blame AI.

EDIT: Also I did not say this is advanced, just not beginner friendly

I feel like I'm a pretty beginner C dev and I could read this. What made this advanced?

It is not beginner friendly but it is optimized. It doesn't allocate memory or whatever. I don't expect you to understand all this but I did it for fun anyway.

int print_file(const char* buffer)
{
    // Validate the buffer
    if (!buffer || *buffer == '\0') return 1;

    // Prepare the first line prefix
    unsigned int line = 1;
    printf("%4d\t", line); // You could pre-format it if u want

    const char* cursor = buffer; // The pointer that points to the first char
    const char* linestart = cursor; // The start of the line
    char ch; // Character register

    while (true) {
        ch = *cursor++; // Read character THEN advance the cursor.

        // Check if the character is null or is newline or windows thing

        if (ch == '\0') {
            int linelength = cursor - linestart - 1; // Minus the null terminator
            printf("%.*s\n", linelength, linestart); // Print line using the length of string
            break;
        } else if (ch == '\n') {
            int linelength = cursor - linestart - 1; // Minus the newline
            printf("%.*s\n", linelength, linestart); // Print line using the length of string
            linestart = cursor;

            printf("%4d\t", ++line); // Print next line prefix
        } else if (ch == '\r') {
            continue; // Ignore the Windows thing
        }
    }
    
    return 0;
}

So there's a couple errors I can see in there: one which causes your issue here, and one that will cause another painful issue, unless you're lucky.

1. malloc(strlen(buffer + 1)); is not the same as malloc(strlen(buffer) + 1);. Your allocation is actually one byte shorter than your input string. This means your strcpy will copy a byte past the allocated buffer. Only bad things can come out of that, and they may not be noticeable at first.
2. The issue you're actually describing here requires maybe a bit better of an understanding of pointers. malloc is giving you back an address - call it 0x0001 - and promises to have at least the available size you requested. You promise to at some point free that address. That address is stored into line. strchr returns a different address - one later in the string, specifically. Your loop continuously advances line to that new address plus one. So, at the end, you've been given an address, 0x0001, and you're trying to free some other address - e.g. 0x10de. That's why you can't free; you're freeing something other than what you malloc'd. You need to hold onto the actual address returned by malloc in another variable, and free that address specifically.

For #1, I'd personally recommend taking a look at strdup instead of malloc + strcpy. It's identical functionally, so I invite you to wholly understand all three functions and understand when/why they're used, but when copying a string exactly, strdup is the way to go - and it removes the possibility of an errant + 1. As part of the understanding, understand that the result of strdup does still need to be given to free eventually.

As a general note, to provide maybe some clarity on "is it fine to not free strings" - strings don't really exist in C. That is, there's not some special thing that the system sees as a string. They're by convention - a string is a blob of non-'\0' bytes that ends with '\0'. malloc and free do not know or care what you did with the bytes you received, and whenever you see a man page say that it does something with a string (copy, search, etc.), you can confidently substitute string with "blob of non-nul bytes ending with a nul byte". "string" just sounds nicer, and by convention, that's what we know a "C string" to be.