That's pretty small for a complete C application...

Various things that I have written in less than 1300 lines of C:

    * TCP proxy (~200)
    * Win32 GUI TOTP authenticator (~230)
    * GIF decoder (~300)
    * PNG decoder (~470)
    * JPEG decoder (~770)
    * H.261 decoder (~740)
    * H.263 decoder (~1100)
    * MPEG-1 decoder (~1100)

All of the above I would consider a "complete C application".

Edit: looks like some people just have no respect for craftsmanship.

You should go back and add error handling to your C programs

Are you implying I don't already have error handling?

Personal insults are not acceptable here.

My dude, how would he know better? It is a perfectly fair assumption given the average C code base. Those numbers are unusually succinct.

You sound like you really know what you're doing, if you can, please share some of this for our edification and don't take things personally.

> Are you implying I don't already have error handling?

With baseless claims, no code, no other consideration? I would not imply that, I would assume that.

post your code

How is a codec a complete application?

Talk is cheap, show me the code.

came to write the same thing. take my upvote.

Your 200 line TCP proxy is likely to be very inefficient.

This is what things like DPDK and io_uring attempt to solve.

So your 200 line proxy... I wonder how it performs compared to this. Since LOC is a silly measure of anything, lets use it further: How many bytes/s/sloc does yours acheive compared to the io_uring one?

Or people have no respect for arrogant boasting.

Also, you most likely are a liar. Just the matrix tables you need for MPEG-1 are 500+ lines.

Unless of course you used 1100 lines to call ffmpeg. Then you don't need the tables.

But that being said: Yes, writing a TCP proxy in 200 lines is indeed possible. But it will use standard socket calls. You might want to read up about what io_uring is all about, and why it's worth going the extra mile.

Or, as an alternative, you could STFU :)

FWIW it's about 800 lines excluding comments.

and yeah, this is why you don't abuse side-by-side divs ... actually, that's a table ... and instead just make your number unselectable (there are several ways to do this).

It aligns perfectly for me. Must've been mostly tested on Firefox.

I am on Firefox...

Doesn't work on Chrome too.

Needs .linenumbers { line-height: 12pt } but I think vertical line spacing within text node cannot be precisely controlled and is browser dependent.

There's something super weird going on with those line numbers. They don't align for me either (Firefox on Windows 11). In the web inspector, the line numbers are rendering with Courier New as the font, whereas the code itself is `monospace`.

The weird thing is both are controlled by a single CSS rule,

    div#cgit pre {
      font-family: "Source Code Pro", "Courier New", monospace;
    }

(Changing to just `monospace` fixes it.)

I'm not sure how two elements could have different fonts with that. I'm possibly missing something obscure, but it really feels like a browser bug.

Great sleuthing, the missing piece of the puzzle is that the file contents are inside a <code> element while the line numbers are not, and <code> elements have a default font so they don't inherit the font from their parent element. Changing the selector to the following fixes the issue:

  div#cgit pre, div#cgit code { ... }

(The buggy CSS is not present in the the official cgit repository, so I assume the owner of kernel.dk is running a patched version of cgit.)