On 24/01/15 07:26, leo(a)yuriev.ru wrote:
Of course, I understand that __VA_ARGS__ are used only for debugging
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
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
For instance, in our fork we plan limit the support to modern
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.