@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).

I'm not familiar enough with this code to give it a proper review, but I suppose I am on the list for gcc compatibility? I checked and a GENERIC kernel does build with this patch applied to head r322969 and

Keep generated stub on one line.

LibAliasSetMode: mav feedback, indicate error via return flags

In D12020#249291, @mav wrote:

I have another idea. Since this function returns resulted flags, it may be possible to make it return as disabled function which has failed to enable. In such case it would both stay compatible with old code and fixed the compilation errors like that, but slightly complicated check for enable error (if somebody really want it).

Hmm. This procedure is exported in userspace libalias, is it okay to change its signature like that? Would you want the flags and mask arguments also changed from unsigned int to int for consistency?