[ldns-users] redefinition of bool, overlap of Z and DO in EDNS

[Jan Včelák]

Hello Willem,

>> I also just noticed that all tags disappeared from the official
>> repository. Please, can you check?
>
> Yes, something went wrong with the move to a new gitlab instance.  They
> should be back now.

Thank you for a quick fix.

>> We have been using ldns in C++ but hit the problem that ldns redefines
>> default bool type in common.h [3]. That breaks some constexpr
>> definitions which involve boolean types and follow that include. Ugly
>> workaround is to include ldns.h and then undefine true, false, and
>> bool. Does the code still make sense today? Can I just update the
>> macro conditions to include stdbool.h with C and do nothing with C++?
>
> Yes that seems more stable than what we have now.  Use of stdbool.h in a
> library is regrettable really.  We have had problems before where the
> type of bool differed during library compile time and library usage.
> Maybe a more stable but still backwards compatible behavioural mechanism
> would be to define a DONT_HAVE_STDBOOL_H when the header was not
> detected during configure..., I'll try to think of something for you to
> review...

Perfect. I'm looking forward to it.

>> And the last thing: The ldns_pkt_set_edns_z() function clears the DO
>> flag. This looks intentional. But the only way to clear all but DO
>> flag in EDNS (if I want to use ldns API) is to read the DO flag, use
>> the function above the clear all flags, and set DO to its original
>> value. This is confusing as EDNS(0) RFC [4] shows Z and DO as separate
>> fields. I was thinking about changing getter/setter function for Z to
>> exclude DO flag. Does it make sense or do you suggest different
>> solution?
>
> Yes, I am conservative to the extreme with changing behaviour with ldns,
> sorry.  I suggest to update the documentation to make it more clear, and
> add another getter/setter that only changes the Z bits.

What do you think about https://github.com/NLnetLabs/ldns/pull/2 ?

Cheers,

Jan