On Mon, Oct 05, 2015 at 01:40:16PM +0200, Jrmie Courr??ges-Anglas wrote: > Mikolaj: note that upstream already has AC_C_BIGENDIAN in its > configure.ac and already uses it... *except* when the system has an > <endian.h> include file. That special case is where the bug was > introduced; what was the reason for this special case?
Okay, I've looked at all this again and I think I know what you mean. That part of the code which I think you are referring to (#if HAVE_ENDIAN_H in par2cmdline.h) didn't change. There was par2cmdline 0.4 in OpenBSD 5.5 and exactly the same version is in OpenBSD 5.6 and __BYTE_ORDER define stopped to be defined properly in 5.6. Your question pointed me to look at endian.h detection under OpenBSD 5.5 and 5.6 for par2cmdline 0.4 (as update to 0.6.14 is unrelated to endianess problem) and bingo: OpenBSD 5.5: checking endian.h usability... no checking endian.h presence... no checking for endian.h... no OpenBSD 5.6: checking endian.h usability... yes checking endian.h presence... yes checking for endian.h... yes config.log for 5.5 says: configure:4611: checking endian.h usability configure:4623: cc -c -O2 -pipe conftest.c >&5 conftest.c:63:20: error: endian.h: No such file or directory openbsd55$ find /usr/include/ | grep endian.h /usr/include/amd64/endian.h /usr/include/sys/endian.h openbsd56$ find /usr/include/ | grep endian.h /usr/include/amd64/endian.h /usr/include/endian.h /usr/include/sys/_endian.h /usr/include/sys/endian.h However, I'm still not sure how to answer your question, about why they wrote par2cmdline.h the way it's written, if it's that what you are actually asking for, Jeremie. -- best regards q#
