[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