Grant's answer is fine, but something here needs to be emphasized.
Doesn't the zlib need to compress ??
No! It does not, and cannot always compress. Any operations that losslessly compress and decompress and input must expand some, actually most, inputs, while compressing only some inputs. This is a simple and obvious consequence of counting.
The only thing that is guaranteed by a lossless compressor is that what you get out from decompression is what you put in to compression.
Any useful compression scheme is rigged to take advantage of the specific redundancies expected to be found in the particular kind of data being compressed. Language data, e.g. English, C code, data files, even machine code, which is a sequence of symbols with a specific frequency distribution and oft repeated strings, is compressed using models that are expecting and looking for those redundancies. Such schemes depend on gathering information on the data being compressed in the first, at least, 10's of Kbytes before the compression starts being really effective.
Your example is far too short to have the statistics needed, and has no repetition of any kind, and so will be expanded by any general compressor.
str1 *= 2already gives you a net gain (although it's an extreme corner case, as such a string is incredibly compressible); my system shows that you go from an increase of 8 bytes to a decrease of 5 bytes.