GZipFile: Remove on-stack allocation

[madmaxoft]

Currently GZipFile::ReadRestOfFile() allocates the result on stack, resulting in 128 KiB stack usage. VS has a soft-complaint about it.

We should change the Compression::Result type to always hold data on the heap. There's no benefit in keeping it stack-based.

[MrSach]

Hello, I would be interested in helping with this.
Where should I start with this memory allocation-related issue?

[madmaxoft]

Hello.
If you are on Windows, MSVC2022 produces a warning when compiling GZipFile::ReadRestOfFile, that should point you in the right direction.
Basically this boils down to removing the Static part of the Storage's variant in Compression::Result in src/StringCompression.h, then fixing everything to work again.

[MrSach]

Thank you for the guidance on this.
I will investigate the error and also check the header and source files for the Static alternative for the Storage variant in question

[MrSach]

Hello, I have read the pages:

• ./GETTING-STARTED.md
• ./CONTRIBUTING.md
• ./COMPILING.md
  and have followed the guidelines where I could.

After cloning the repository, I have changed a line in the StringCompression header file and a few blocks of code in the source file.
Having compiled the modifications on Visual Studio, I do not see any warnings for these header and source files now.

Should I show what changes I propose for the following before initiating a draft Pull Request?:

• ./src/StringCompression.h
• ./src/StringCompression.cpp

[madmaxoft]

Sure, go ahead, a draft pull request is the best way to check if you're heading in the right direction.

[MrSach]

More commits have been added earlier this week to the draft pull request.
These propose a more suitable data type for storing compressed/uncompressed data.
Some commentary has been added to the header and source files.