Always nice to have minus diffs, assuming it still compiles :)

Most of these changes look to be in the right direction. I don't think evaluating if a bool == true or == false is necessary. In some places parentheses have been added which are not strictly needed, I don't feel strongly about those either way. I did not evaluate for completeness.

My opinion is generally that branch predictions should be sparse. Is it really going to make any difference in setup/teardown functions, which many of the functions edited here appear to be?

Review feedback: avoid touching "superfluous" macro parens for now

mjoras feedback: parenthesization fixes

In D12753#264690, @mjoras wrote:

The superfluous parentheses stuff is sort of nitpicky, but I do feel that at least in the case where the expansion is surrounded by commas then it should be dropped since comma operators / separators have the lowest possible precedence.

In D12683#263679, @pfg wrote:

Upstream indeed seems to have disappeared but Benno Rice may know better.

In D12675#263212, @hselasky wrote:

Just give this patch a spin with clang aswell before committing. I'll handle this issue towards Mellanox.

Thank you!

--HPS

hselasky feedback: replace const vars with enum constants

In D12675#263187, @hselasky wrote:

What is the purpose of this change?

Padlock fix-up LGTM.

The change looks fine to me.

Just dropping some nitpicks, I haven't reached a deep enough understanding for a real review yet.

The change itself seems fine to me. I'll defer to others with respect to whether this is the right direction and whether the documentation needs to be in this revision.

@emaste suggested out of band to verify with a universe build. I did a make tinderbox and it succeeded.

In D12284#254932, @emaste wrote:

In D12284#254878, @rlibby wrote:

It appears to have been in upstream: ftp://ftp.iana.org/tz/code/zic.c (see oadd).

As for when we might sync with upstream next, I have no idea. Last sync appears to have been in 2010.

We could also bring in that fix independently, in advance of a full update.

In D12284#254856, @ngie wrote:

When will zic(8) be fixed?

bdrewery feedback: restore old comment

Typo, s/modrm.rm/modrm.reg/

So, @imp, what's your preference in terms of direction here?

In D12211#253286, @rlibby wrote:

I can check if just -fno-strict-aliasing quiets the warnings.

In D12211#253285, @imp wrote:

In D12211#253284, @rlibby wrote:

In D12211#253281, @imp wrote:

This is upstream code.
The warning should be disabled instead.

Whoops, didn't realize. I see lib/libefivar/FreeBSD-update now. So, am I reading it right then to understand that efivar-dp-parse.c is from an upstream, but uefi-dplib.h (modified in D12210) is just in FreeBSD?

I'll check if there's anything else to be done with the flags when building this.

That's correct. I'd like to understand why your version works, since I seem to recall needing the cast to make it work due to some instances of y being char * or some other pointer and your proposed fixed may just silently break things.

In D12211#253281, @imp wrote:

This is upstream code.
The warning should be disabled instead.

By the way the files in this review still have the wrong mode bits (100755 instead of 100644, need chmod a-x).