[Date Prev][Date Next]
Re: (ITS#8018) a lot of warnings building with -Wall
On 01/12/2015 05:22 PM, email@example.com wrote:
> 2015-01-12 17:19 GMT+03:00 Hallvard Breien Furuseth <
>> The Debug() change is going to give merge conflicts all over
>> the place when your <https://github.com/ReOpen/ReOpenLDAP> and
>> OpenLDAP pull updates from each other.
>> https://github.com/ReOpen/ReOpenLDAP should not be used for merge, but
> only for cherry-picking.
Oops, right. "cherry-picking conflicts":-)
> It has stripped history and merged with OpenLDAP/mdb.master, because
> mdb.RE/0.9 don't includes a few critical fixes (ITS 7969,7970,7971) for our
> I think that is the reason for patch conflicts.
> Patchset got RE25 should remain among my sent emails. Presumably I can send
> it for you again, if you are interested.
No, I was talking about maintaining the two projects in the future.
Presumably you'll want to copy fixes from OpenLDAP, and we'll want
fixes from you. Any such change next to a Debug() statement will
not apply cleanly, and must be hand-edited.
>> How about defining Debug1(), Debug2(), etc for 1,2... arguments?
>> That's still annoying, but it keeps the code C90-compatible and
>> keeps -Wformat quiet. There's already similar code for Log<N>()
>> in include/ldap_log.h, but it was never used much or even merged
>> into RE24. (Because it got scheduled for RE25 which was going to
>> start Real Soon Now, IIRC:-)
> IMHO the Log<N> recipe is onerously for support.
> On other hand, nowadays all non-obsolete compilers support most of C99
> Baseline features, such as "variadic macro", supported long ago (Microsoft
> was the most conservative to 2012).
> Maybe it is time to enable C99 in RE25?
Dunno. People do use old compilers. OpenLDAP is conservative about
portability. It requires C90 to build, but exports K&R1-compatible
headers. Well, it tries. K&R1 compat was broken by OpenLDAP 2.0
(ITS#6171) and nobody who cares about K&R1 has bothered to fix it.
When we do move towards C99, maybe we'll first test the waters by
making Debug() use __VA_ARGS__ but not change the Debug() calls yet,
so we'll only have a few lines to revert it it proves premature.
We'll hear what Kurt says.