Hi, Thanks for report. Good job.
> and that does not sit well with the documentation for MacOSX i386 > assembler: > https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html > > suggesting that the .comm directive takes two operands, while .lcomm > takes an optional third operand. > > Other documentation https://sourceware.org/binutils/docs/as/Comm.html > states "When using ELF or (as a GNU extension) PE, the .comm directive > takes an optional third argument". 32-bit MacOSX uses neither ELF nor > PE. The third argument ought to be redundant here; the default natural > alignment as described in the Apple developer documentation ought to be > adequate. Apple 'as' stems from some ancient version and you shouldn't try to apply contemporary documentation literally. The fact that it didn't accept alignment for .comm was obviously missing feature (the fact that it was fixed is the proof). The reason for change on MacOS was desire to keep things harmonized with other platforms. > It's not clear to me that me ought to do anything; this is a problem > only when building using compilers for MacOSX releases that have long > since been EOLed. Well, if you can confirm following, then it would still be appropriate to revert that change. Compile following snippet with -sectalign __DATA __common 4 argument and post nm output for resulting binary. .text .globl _main _main: ret .comm _one,4 .comm _two,8 .comm _four,16 Goal is to confirm that _two and _four are actually aligned at their sized even though section alignment is relaxed. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
