libefivar: avoid type-punning in DevPathFromTextFibreEx

[rlibby]

Summary

This avoids the -Wstrict-aliasing warnings remaining after D12210.

Test Plan

buildworld with gcc, examine log

[imp]

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

[rlibby]

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.

[imp]

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.

[rlibby]

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.

Yes, I see the concern. After a quick look through, I don't notice any problems, but I do notice where code is specifically avoiding this problem, like this:

Strtoi64 (StartingAddrStr, &StartingAddr);
WriteUnaligned64 ((UINT64 *) &(RamDisk->StartingAddr[0]), StartingAddr);

I can see that this may be more fragile w.r.t. changes from upstream. I can check if just -fno-strict-aliasing quiets the warnings.

[rlibby]

In D12211#253286, @rlibby wrote:

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

I checked, and it does, so there is that option.

[rlibby]

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

TL;DR: What do you think of just adding -fno-strict-aliasing to the libefivar CFLAGS and calling it a day?

My goal is just to get the gcc build working, including in-tree gcc 4.2.1 in stable/11. I don't particularly care to address warnings in upstream code, and I see your concern with respect to breaking code that might rely on the cast (re D12210).

That said, I did try D12210 with gcc and -Wconversion. gcc -Wconversion is unfortunately not smart enough to actually turn on (many false positives), but I didn't notice any conversion that it warned about as a result of Strtoi64 (except sign conversion, which I assume would be fine).

Finally another option could be to use -Wno-error=strict-aliasing (with appropriately different spelling for gcc and clang) but I think this is inferior to -fno-strict-aliasing, assuming we don't care too much about performance of libefivar.