On Thu, Jan 13, 2022 at 11:02 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > Aside from what René said in his follow-up, I think what Junio's > pointing out here has to do with the use of this pattern in general, not > the specific code being discussed here. > > I.e. if you get into the habit of needless initialization it may not > matter right now, but once the function grows an if/else branch, or > someone copies the pattern to such a function it may hide a logic error. > > So it's not about analyzing the control specific flow here, but that > your upthread patch is separating a variable and its actual > internalization by ~20 lines. I know this is the Git project's preferred style, so I'm OK with adapting to that, but I'm also sad about it. Sure, you can introduce logic errors by refactoring things, but with initialized data, you get a reproducible logic error, rather than something whose failure mode depends on platform, compiler and surrounding function calls. This makes debugging problems across platforms easier. In particular, I don't have a functioning Windows environment, so anything that helps minimize differences across platforms is welcome to me. -- Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
