Latest Xcode update violates POSIX compliance of `nm -P`
TLDR: Apple messed up again and broke POSIX compliance
luite ran into problems when he installed the latest Xcode update because the derived platform constants were off.
He provided me the output of
nm -P ./includes/dist-derivedconstants/header/tmp.o which turned out to have numbers which didn't make sense:
_derivedConstantAP_STACK_SPLIM C 1025 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C 253 0 _derivedConstantBLOCK_SIZE C 4097 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ...
Which with an older Xcode version would have looked like
_derivedConstantAP_STACK_SPLIM C 401 0 _derivedConstantBITMAP_BITS_SHIFT C 7 0 _derivedConstantBLOCKS_PER_MBLOCK C fd 0 _derivedConstantBLOCK_SIZE C 1001 0 _derivedConstantCINT_SIZE C 5 0 _derivedConstantCLONG_LONG_SIZE C 9 0 _derivedConstantCLONG_SIZE C 9 0 _derivedConstantDOUBLE_SIZE C 9 0 _derivedConstantDYNAMIC_BY_DEFAULT C 2 0 ...
nm -P's output changed from hexadecimal to (non-compliant) decimal formatting of numbers.
For reference, here's how POSIX specifies the semantics of
-PWrite information in a portable output format, as specified in the STDOUT section.
-Poption is specified, the previous information shall be displayed using the following portable format. The three versions differ depending on whether
-t o, or
-t xwas specified, respectively:
"%s%s %s %d %d\n", <library/object name>, <name>, <type>, <value>, <size>
"%s%s %s %o %o\n", <library/object name>, <name>, <type>, <value>, <size>
"%s%s %s %x %x\n", <library/object name>, <name>, <type>, <value>, <size>
-Pis specified, but
-tis not, the format shall be as if
-t xhad been specified.
In the event that Apple can't be bothered to fix this bug (I've had bad experience with Apple and standard-compliance in the past, hence my pessimism) we could try to workaround by using
nm -P -t x when building on OSX...
Alternative workaround (since it turns out that Apple's
nm violates POSIX even more than assumed by not even supporting
nm -P -t x):
deriveConstants derive a known value, e.g. the value
char derivedConstantCONTROL_GROUP[1+0x1234];, and if the value for
CONTROL_GROUP comes back as
18016 we know that we need to fixup all decimal-wrongly-as-hex parsed integers, if it comes back as
4660 we parsed correctly; any different value is a non-recoverable error
This would also serve as a general integrity check for //all// platforms