Em qua., 24 de ago. de 2022 às 16:00, Tom Lane <t...@sss.pgh.pa.us> escreveu:
> Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: > > On 24.08.22 16:30, Alvaro Herrera wrote: > >> If you do this, you're creating a potential backpatching hazard. This > >> is OK if we get something in return, so a question to ask is whether > >> there is any benefit in doing it. > > > I don't follow how this is a backpatching hazard. > > Call me a trogdolyte, but I don't follow how it's an improvement. > It looks to me like an entirely random change that doesn't get rid > of assumptions about what the bits are, it just replaces one set of > assumptions with a different set. Moreover, the new set of assumptions > may include "there are no padding bits in here", which is mighty fragile > and hard to verify. So I frankly do not find this a stylistic improvement. > But, these same arguments apply to Designated Initializers [1]. like: struct foo a = { .i = 0, .b = 0, }; That is slowly being introduced and IMHO brings the same problems with padding bits. regards, Ranier Vilela [1] https://interrupt.memfault.com/blog/c-struct-padding-initialization