[MacPorts] #67790: ht: Fix arm64 compilation
MacPorts
noreply at macports.org
Fri Jul 21 19:15:42 UTC 2023
#67790: ht: Fix arm64 compilation
--------------------------+----------------------------
Reporter: rdoeffinger | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords: arm64 haspatch
Port: ht |
--------------------------+----------------------------
Comment (by rdoeffinger):
I agree that ideally we will get a response from upstream, just not sure
how active they are.
So I'll provide a basic explanation what I think goes on here.
A lot of the structs in this file are meant to be serialized out into
buffers.
HT_TAG_BUFOP adds functions like flush() that memcpy them and also special
serialization functions in the .cc file.
For that you'd want them packed, because both you'd not want random data
from the padding to leak out and also for the size and layout to not
depend on architecture/OS/compiler.
However in case of ht_tag_flags_s I suspect that PACKED was added by pure
accident.
Why? First of all, PACKED was added in 5c0c87f2 along with all other
structs in the file, so likely it was not closely reviewed.
Second of all, this struct contains no HT_TAG_BUFOP, and it is the only
one containing a pointer type. And it's not really possible to sensibly
serialize a pointer to a buffer (without some special logic, which does
not exist here).
I think, it is rather the opposite, the ht_tag_flags_s are a mapping
between the values being serialized out and the strings they stand for, so
they are explicitly meant to live only in the binary, not the buffers that
are created here.
Thus I do think the change makes sense, however I agree it is sensible to
wait a while and see if we can get an upstream response.
I guess the only counter-point is, for AppleSilicon devices it currently
does not compile at all, so applying it only for that case does not really
make anything worse even if I'm wrong...
--
Ticket URL: <https://trac.macports.org/ticket/67790#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list