Oh God, I'm making a WEB FRAMEWORK; I SHOULD NOT be doing assembly! 😩

Somewhere during re-implementing this sh*ty library, I f*cked up; and now I'm trying to triple debug my way out of this self-dug hole!

For Web++ I needed to have header-only C++ compliant version of liburing, so I've forked it and did that.

There are still some UBs and Compiler-Specific stuff that I need to sort out, but right now it's a drop-in replacement.

I would like to have liburing's repo itself to host the header-only version of this as well so both header-only and future versions of liburing can be packages in one repo and grow together; but there are non-compatible changes in the header-only version which CAN be managed but not merged directly.

It's
- Header Only
- No Undefined Behaviors
- Standard compliant (No compiler-specific features)
- pedantic friendly
- C and C++ compatibility without any extern "C" or extern "C++"es



Some of the changes so far:

- removing of all .c files
- moving the implementations into liburing.h
- adding static inline to their definition
- removing configure script
- doing `compat.h` manually without needing to be generated
- using KERNEL_VERSION and LINUX_VERSION_CODE for feature detection and fallback instead of relying on configure script
- adding liburing-hdr-only.h for clear distinction between header-only and original version if required by the user
- adding noexcept pretty much everywhere :smile:
- Casting
- added uring_static_cast and uring_reinterpret_cast
- trying to use io_uring_start_lifetime (not fully done yet)
- using io_uring_next_void_ptr in order to do void pointer arithmetic in an standard way
- Using nullptr instead of NULL (with fallback of course)
- Provide missing values on construction on initialization
- Adding some consts here and there, and moving declarations of variables from beginning of the functions to their first use.
- Assembly changes:
- C++ can't do the return technique used for calling the assembly codes, so I changed the assembly macros in a way that they fill a variable named ret and then we can use that while using the macros.


There are more small changes as well, and I have probably created a few problems as well, but I hope I can fix them.


Here's the link to the fork containing the changes said above.
Here's the issue link, that's me trying to see if I can merge this fork into the original repo.

I like bit manipulating!

2023-10-14: Working on web++'s scheme parser of the URI parser.

2023-10-15: Continuing to work on the URI parser.

Recorded using asciinema, replay with 50x speed.

The whole thing is in terminal using neovim with SpaceVim installed on it.

I like my bits manipulated 😁

Did you know you couldn't use hex numbers as IPv4 octets, but you kinda can? In WHATWG compliant URL Parsers, it's a warning, not an error:

» http://127.0.0x10.1
is same as:
» http://127.0.16.1

I don't agree with this decision though, and also it messes up my error handling ideas that I had in mind, but ...!

You already can use this in your browsers, you can write http://0x7F.0x0.0x0.0x1, you'll get http://127.0.0.1/.

Also http://0x7F000001 is going to be http://127.0.0.1 as well.

C++23's [[assume(...)]] fallback looks like this.

And it only took me something like 50+ browser tabs to figure this out 😅

Source on Github

I updated this just a bit to add constexpr support as well; I WENT OVERBOARD, I think 😅.

P.S.: 30+ more tabs got opened as well to get this update 😂

New source code on Github
Test: Godbolt Link

Opened up 2 PRs for boost::coroutine and boost::context to fix similar casting warnings in them.

Turns out my IPv6 Parser implementation can correctly parse IPv4s, but it shouldn't, raw valid IPv4s are not valid IPv6s. 😅

Merged the upstream changes (which is aiming to become liburing 2.6).

There are some issues left still!

Some people think:

I'm over my head

What do you think?