Updated my C++ implementation of the Javascript encodeURIComponent and decodeURIComponent functions; it's now faster.
🔥1
Opened up 2 PRs for boost::coroutine and boost::context to fix similar casting warnings in them.
Web++: A C++ Web Framework
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…
Merged the upstream changes (which is aiming to become liburing 2.6).
There are some issues left still!
Some people think:
What do you think?
There are some issues left still!
Some people think:
I'm over my head
What do you think?
Browsers make mistakes too
There are a few bugs with the current implementation of URL Parser for firefox. (Chromium has them too, but that's another bug).
This URL:
Should be equal to this URL (from ada-url):
I'm writing a WHATWG-compliant URL Parser, so that's why I'm noticing these kinda stuff.
It seems like URL parser of Firefox has a bug which doesn't decode the last segment of the path for some reason.
For example,
is just
There are a few bugs with the current implementation of URL Parser for firefox. (Chromium has them too, but that's another bug).
This URL:
http://127.0.0.1/..//./one/%2E./%2e/two/././././%2e/%2e/.././three/four/%2e%2e/five/.%2E/%2e
Should be equal to this URL (from ada-url):
http://127.0.0.1//three/
| | |
| | `------- pathname_start 16
| | `------- host_end 16
| `---------------- host_start 7
| `---------------- username_end 7
`------------------ protocol_end 5
I'm writing a WHATWG-compliant URL Parser, so that's why I'm noticing these kinda stuff.
It seems like URL parser of Firefox has a bug which doesn't decode the last segment of the path for some reason.
For example,
http://localhost/page/%2e%2eis just
http://localhost/Did you know these two are VALID URLs and are the SAME?
file://C|\windows
file:///C:/windows
😐1
Web++: A C++ Web Framework
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…
All of these URLs refer to the same place:
😐😐😐😐😐
http://127.0.0.1/
http://0x7F.1/
http://0x7F000001
http://0x0000000007F.0X1
http://127.0.0x0.1
http://127.0X0.0x0.1
http://127.0X0.0x0.0x1
http://127.0.0x0.0x0000000000000000000000000000000000000000000000000000000000000001
http://0x7F.0x00000000000000000000000001
http://0x000000000000000007F.0x00000000000000000000000001
http://0x000000000000000007F.0.0x00000000000000000000000001
http://0x7F.0.0.0x1
http://0x7F.0.0x000.0x1
http://2130706433
http://127.1
http://127.0x00.1
http://127.0x000000000000000.0.1
😐😐😐😐😐
🤔1
Use clang-format, they said!
Updated my
.clang-format and ran it on all the files, it broke a lot of things.I had to spend hours going through all the changes one by one.
After doing this, I surprised myself; I didn't expect to have written this much code over the past few years.
Turns out I missed some bugs: the issue
My tests are crashing,
- but only in clang, (reasonable, right?)
- and not if each unit test run individually (but, how??)
How does it know I'm filtering the tests?
- but only in clang, (reasonable, right?)
- and not if each unit test run individually (but, how??)
How does it know I'm filtering the tests?
Truth will prevail after I force some gdb/lldb serum down its throat.
👍1👀1
Web++: A C++ Web Framework
My tests are crashing, - but only in clang, (reasonable, right?) - and not if each unit test run individually (but, how??) How does it know I'm filtering the tests? Truth will prevail after I force some gdb/lldb serum down its throat.
This media is not supported in your browser
VIEW IN TELEGRAM
Upgraded it to crash on GCC as well 😅
Oooph, that's it for today 😬
Oooph, that's it for today 😬
😁1