On 24/01/15 07:26, leo@yuriev.ru wrote:

Of course, I understand that __VA_ARGS__ are used only for debugging currently.

Aha, a misunderstanding there. Debug() is _not_ just for debugging, it's also for logging. "Rebus" coding, as you say:-( 20 years of cruft in the code. I see you've talked about that in ITS#8015, so I'll answer the rest there instead.

But this is makes me think that recent development and testing of OpenLDAP are carried out only in today's environment (modern Linux and gcc).

Certainily not. _Mainly_ on a few platforms, probably. People submit bug reports about other platforms, Howard once in a while says "I tested on <that platform> and did/did not find your problem", etc. See the commit logs and mailinglists, and the Build Environment part of CHANGES in REL_ENG: gcc-isms and other stuff creep in, and get thrown out again.

Could anyone say about the list of a system-compiler pairs with which OpenLDAP was tested or just successfully compiled?

Not to my knowledge. We just try to keep the code portable, within some constraints like we don't support weirdness like 32-bit 'char'.

For instance, in our fork we plan limit the support to modern systems with gcc, clang and last msvc compilers.

That's incompatible with our coding practice. We just try to keep the code portable, within some constraints like we don't support weirdness like 32-bit 'char' and some religious disagreements about what portability is. Anyway, if some code isn't portable, it needs a good excuse for getting in and staying in.

Note that lots of unportable code can be writtene portably, or at least it can keep the unportability in one place. E.g. your repo's change of /bin/sh to bash is not an option for us. But maybe tests/run.in and tests/scripts/all could be changed to optionally invoke them with another shell.