Web++: A C++ Web Framework
Huh, monotonic_buffer_resource is the one with growth factor! I did not expect this one at all!
Turns out I was wrong about monotonic buffer resource.
It seems I was wrongly assumed that growth factor is being used inside "do_allocate", it's not; so it's not monotonic's fault that we can't know the required size.
I had to re-check the monotonic buf res's implementation and write a few tests.
Tweet Link | Compiler Explorer Code | Source Code of the tests
Do you have a cooler way of optimizing away certain cases of a switch statement with an if-constexpr?
These things affect the generated assembly.
These things affect the generated assembly.
Parsing IPv4 in a host of a URL requires different algorithm than the good old
So I now have both of them implemented; of course I have to benchmark them.
Turns out on GCC, the newly URL's Host's IPv4 Parser is faster; which is just weird to me since the IPv4s in the URLs are looser and have a bit more features (which I don't think they should have in the first place).
The IPv4s in the URLs:
- can have Hexadecimal numbers
- can have Octal numbers
- the last octet can hold the value of the remaining ocets
This means, all of these are invalid in
inet_pton4 (which I have implemented before).So I now have both of them implemented; of course I have to benchmark them.
Turns out on GCC, the newly URL's Host's IPv4 Parser is faster; which is just weird to me since the IPv4s in the URLs are looser and have a bit more features (which I don't think they should have in the first place).
The IPv4s in the URLs:
- can have Hexadecimal numbers
- can have Octal numbers
- the last octet can hold the value of the remaining ocets
This means, all of these are invalid in
inet_pton4, but valid in the URLs:"0000000.0.0.0"
"0x000000.0.0.0"
"0X0000.0x.0.0"
"0"
"0x"
"0X
"00000"
"0x0000"
""
"."
"127.0.0.1"
"0x7f.1"
"0x7f000001"
"0x0000000007f.0x1"
"127.0.0x0.1"
"127.0x0.0x0.1"
"127.0x0.0x0.0x1"
"127.0.0x0.0x0001"
"0x7f.0x0000001"
"0x0007f.0x0001"
"0x007f.0.0x00001"
"0x7f.0.0.0x1"
"0x7f.0.0x000.0x1"
"2130706433"
"127.1"
"127.0x00.1"
"127.0x000000000000000.0.1"
"000123"
"0xff"
"1.256"
These two URLs result in different strings generated!
WHATWG is written by idiots.
Browsers are doing their own thing btw!
file://localhost/path/to/somethere
file://127.0.0.1/path/to/somewhere
WHATWG is written by idiots.
Browsers are doing their own thing btw!
😁1
WHATWG mindset:
-
-
-
file::::::: totally valid URL-
http:: hold on, that's not valid at all!😁2🔥1🤣1
This is a valid WHATWG URL with a hidden "Hello World" binary message encoded within:
-
-
-
/ is 1-
\ is 0https:/\\//\\////\\\\//\\/\\/\\\\/\\\\///\\\\/\\\\///\\\\/\\\\\\\\//\\//////\\/\\/\\\\\\/\\\\/\\\\\\\\/\\\\\\//\\//\\\\/\\\\///\\\\//\\//example.com👍1
I don't know whom is to blame, but this is a valid URL:
fILe://C|\\//\////\\\\/\/\/\\\/\Why on earth tabs and newlines are just IGNORED in URLs and spaces are invalid characters?
WHO hurt you WHATWG?
WHO hurt you WHATWG?