Got it ... given that I dont't really want to patch all of cares_wrap.cc, would it be ok to patch this section verbatim into cares_wrap.h?

It seems indeed that libcares exposes these for NodeJS exclusively, at least for now ...https://github.com/c-ares/c-ares/issues/415

On 1/7/22 17:31, Stuart Henderson wrote:
On 2022/01/07 15:14, Volker Schlecht wrote:
Hi,

while working on a port for NodeJS 16.x, I noticed that net/libcares
provides a /usr/local/include/ares_nameser.h that doesn't work on OpenBSD:

In Lines 68 through 178, the enum ns_rcode, ns_opcode, ns_type are only
defined if CARES_HAVE_ARPA_NAMESER_H is not defined. OpenBSD has
arpa/nameser.h but it doesn't define those enums.

As per the comment, c-ares makes the assumption that arpa/nameser.h should
define them:

/*
============================================================================
* arpa/nameser.h should provide these enumerations always, so if not found,
* provide them
*
============================================================================
*/


I'm not sure if the right approach would be to define those enums in
OpenBSDs arpa/nameser.h (FreeBSD and Linux seem to do that) or to remove the
condition from the include File in the c-ares port, or if there's another
even better solution?

c-ares itself only uses those enums if the other macros (SERVFAIL,
NOTIMP, REFUSED, etc) aren't defined (which they are), so it's not a general
"the c-ares headers don't work" problem.

If you look at the sample code in c-ares and various other software
using c-ares they're all using T_XXX so I think node's cares_wrap.cc is
doing things wrong in this case and should probably change to T_XXX too.

In more general-purpose use i.e. not for software using c-ares, ns_t_xxx
is more common and it would be nice if our nameser.h worked the same way as
pretty much every other OS so we didn't have to keep patching things, but
I think that's an orthogonal problem (and last time I mentioned that
problem deraadt@ looked at it and didn't seem terribly happy about
changing things...)


Reply via email to