Noah Misch <n...@leadboat.com> writes: > On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote: >> Looks legit, and at least per commit 13bba02271dc we do fix such things, >> even if it's useless in practice. >> Given that no buildfarm member has ever complained, this exercise seems >> pretty pointless.
> Later decision to stop changing such code: > https://postgr.es/m/flat/e1a26ece-7057-a234-d87e-4ce1cdc9e...@2ndquadrant.com I agree that this seems academic for any sane implementation of memcmp and friends. If the function is not allowed to fetch or store any bytes when the length parameter is zero, which it certainly is not, then how could it matter whether the pointer parameter is NULL? It would be interesting to know the rationale behind the C standard's claim that this case should be undefined. Having said that, I think that the actual risk here has to do not with what memcmp() might do, but with what gcc might do in code surrounding the call, once it's armed with the assumption that any pointer we pass to memcmp() could not be null. See https://www.postgresql.org/message-id/flat/BLU437-SMTP48A5B2099E7134AC6BE7C7F2A10%40phx.gbl It's surely not hard to visualize cases where necessary code could be optimized away if the compiler thinks it's entitled to assume such things. In other words, the C standard made a damfool decision and now we need to deal with the consequences of that as perpetrated by other fools. Still, it's all hypothetical so far --- does anyone have examples of actual rather than theoretical issues? regards, tom lane
