Remove excessive .reserve calls, remove unexplained check

[hrydgard]

I don't see a path where that check could reasonably be hit, so removing it until we figure it out, due to its perf critical location, as commented by Unknown.

Also, remove a bunch of excessive .reserve calls from #18557

[anr2me]

Regarding reserve, i also experiencing a strange issue where i need to reserve at least 1 element when reusing a vector after clearing it while i was working on sceHttp implementation (as commented at #18003 (comment)), where begin() returning null instead of an iterator/object, and i couldn't find any documentation that stated that begin() can returns a null anywhere (which is why it's a strange case as there are no documentation that mentions that this can happen), for example this documentation (which is quite detailed) https://en.cppreference.com/w/cpp/iterator/begin

Resulting any attempt to use the [supposed to be] object in normal way (ie. assuming it's an object per documentation) could triggered an exception/crash.

PS: i haven't tested the issue on linux build, in case it was a compiler bug that only occurred on windows.

[hrydgard]

Huh, that is quite surprising!

[unknownbrackets]

Well, that happens because you can't take a pointer to an empty (capacity) vector. It's kinda dangerous anyway.

For begin, "If the container is empty, the returned iterator value shall not be dereferenced." Basically, you shouldn't use it. I don't see why null wouldn't be a valid return value in that case.

It's really an implementation detail that reserve() makes begin() return something dereferenceable for a zero-length vector. It might change based on optimization settings or compiler or libc++ variant or whatever. It's definitely not a safe thing to do.

-[Unknown]

[hrydgard]

Yeah, indeed - reserve really doesn't mean you are allowed to call begin - that's a bug. still, surprising that the implementation is like that.

[anr2me]

Of course, begin() of an empty vector shouldn't be dereferenced, but it should still be usable for insert for example, meanwhile if begin() is null insert would failed, or even triggered an access violation if insert internally tried to access memory address 0x0 because of it.

Anyway, just now i tried to reproduce the issue by removing the reserve, and apparently the issue didn't happened anymore O.o may be because i'm using a newer version of VS2022 than the last time i debug it, it used to be consistently crashed due to trying to access memory address 0x0.