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
2 problems with using standard containers with stack-based allocators:
1. No allocator, or resource exists for it that's not monotonic (
2. Containers allocate more than needed, thus making it hard to guess the stack size
Writing a memory resource like
But for the second problem, any solve for that requires knowledge of the containers being used which means tightly coupling the containers with the stack size being used which is not a good solution in my opinion.
What do you think?
Compiler Explorer link 1
Compiler Explorer link 2
1. No allocator, or resource exists for it that's not monotonic (
monotonic_buffer_resource that actually deallocates)2. Containers allocate more than needed, thus making it hard to guess the stack size
Writing a memory resource like
monotonic_buffer_resource that does deallocate is not that hard (I might write one), so the first problem is easily resolvable.But for the second problem, any solve for that requires knowledge of the containers being used which means tightly coupling the containers with the stack size being used which is not a good solution in my opinion.
What do you think?
Compiler Explorer link 1
Compiler Explorer link 2
Web++: A C++ Web Framework
2 problems with using standard containers with stack-based allocators: 1. No allocator, or resource exists for it that's not monotonic (monotonic_buffer_resource that actually deallocates) 2. Containers allocate more than needed, thus making it hard…
Huh,
monotonic_buffer_resource is the one with growth factor! I did not expect this one at all!