Rohit Ashiwal <rohit.ashiwal265@xxxxxxxxx> writes: > On 2019-04-13 1:34 UTC Jeff King <peff@xxxxxxxx> wrote: > >> What is gzwrite()? >> [...] >> I think it would be less confusing if this just factored out >> write_block_or_die(), which starts as a thin wrapper and then grows the >> gzip parts in the next patch. > > You are right, it might appear to someone as a bit confusing, but I feel > like, this is the right commit to put it. Often, the original author is the worst judge about the patch series organization, because s/he has been staring at his or her own patches too long and knows too much about them. Unless the author is very experienced and is good at pretending to be the first-time reader when proofreading his or her own patch, that is. FWIW, I tend to agree with Peff that the organization would become much easier to follow with "first refactor without new feature, and in gzip related step add gzip thing". >> Is it OK for us to ask about the truthiness of this opaque type? That >> works if it's really a pointer behind the scenes, but it seems like it >> would be equally OK for zlib to declare it as a struct. Or a small integer indexing into an internal array the library keeps track of ;-) At that point, truthiness would be completely gone, and the compiler would not help catching "if (opaque)" as a syntax error (if the library implements the opaque thing as a structure, then we will be saved). > It would be perfectly sane on zlib's part to make gzFile a struct, and if > so happens, I'll be there to refactor the code. We do not trust any single developer enough with "I'll do so when needed"---in practice, it will often be done by somebody else, and more importantly, we would want anybody to be able to take things over, instead of relying on any one "indispensable contributor". If it is reasonable to expect that things can easily be broken by an external factor, I'd prefer to see us being defensive from day one.
