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 :)