mirror of
https://github.com/morluto/rea.git
synced 2026-11-09 00:07:18 +00:00
Vinícius Andrade
4b653fe6ad
* fix(native): apply printed lipo capability bits to CPU subtypes lipo -detailed_info prints a slice's capability byte separately from its symbolic subtype: CPU_SUBTYPE_LIB64 for x86_64 and ppc64, and other bits as hex. Only the arm64e pointer-auth form was applied, so a LIB64 x86_64 slice normalized to subtype 3 while its FAT entry carries 0x80000003, and slice validation rejected the universal binary as an integrity mismatch. Fold the printed capability byte into the subtype code. * fix(native): leave lipo CPU subtypes unknown without capability bits The lipo shipped with macOS 26 prints an empty capabilities line for x86_64 slices whose FAT capability byte is 0x80 as well as 0x00, so a symbolic subtype alone does not identify the slice's CPU subtype. The parser assumed no capability bits and still reported subtype 3 for LIB64 slices, which made universal applications such as Sublime Text fail slice validation. Report the subtype code as unknown when lipo prints no capability byte, as arm64e already does; slice validation then relies on the remaining physical facts. * test(native): cover printed and blank lipo capability bits Fold CPU_SUBTYPE_LIB64 and hex capability bytes into x86_64 subtype codes, and keep the code unknown for the blank capabilities line that macOS 26 lipo prints. * test(native): match a LIB64 x86_64 slice with blank lipo capabilities Read a universal image whose x86_64 FAT entry carries 0x80000003 while lipo reports CPU_SUBTYPE_X86_ALL with a blank capabilities line, as macOS 26 lipo does, and expect both slices instead of an integrity failure. * fix(native): compare named lipo subtype bits without capability bytes A blank capabilities line leaves the subtype code unknown, and slice matching then skipped the subtype entirely. A FAT entry whose named subtype differs, such as CPU_SUBTYPE_ARM64_V8 recorded by lipo as CPU_SUBTYPE_ARM64_ALL, was accepted. Keep comparing the complete subtype when lipo printed its capability byte, and otherwise compare the subtype bits its record names. * test(native): share LIB64 slice reader setup Read the LIB64 universal fixture through one helper that takes the x86_64 subtype lipo reports, so further cases reuse the same image and lipo record. The existing expectation is unchanged. * test(native): reject a blank-capability lipo subtype naming other bits With the capabilities line blank, a lipo record naming CPU_SUBTYPE_X86_64_H for the x86_64 LIB64 slice still disagrees with the FAT entry's subtype bits and fails slice validation.