Matthew DeVore <matvore@xxxxxxxxxxx> writes: >> It is brittle because callers are bound to forget doing "if >> (!x->buf.buf) lazy_init(&x->buf)" at some point, and blindly use an >> uninitialized x->buf. Making sure x->buf is always initialized > > A corallary proposition would be to make this particular strbuf a "struct > strbuf *" rather than an inline strbuf. It should then be rather clear to users > that it may be null. Would make it less likely for uses of an uninitialized strbuf to be left undetected as errors? I guess so, and if that is the case it would definitely be an improvement. But initializing the strbuf at the point where the enclosing structure is initialized (or calloc()'ed) is also a vaiable option, and between the two, I think that would be even more robust. There may be reasons why it is cumbersome to arrange it that way, though (e.g. if the code does not introduce a "new_stuff()" allocator that also initializes, and instead uses xcalloc() from many places, initializing the enclosing structure properly might take a preliminary clean-up step before the main part of the patch series can begin).
