Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Jun 1999 01:09:19 -0600
From:      Wes Peters <wes@softweyr.com>
To:        John Plevyak <jplevyak@inktomi.com>
Cc:        lab@gta.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Possible conflict in nameser.h
Message-ID:  <37577B9F.93DB3DD0@softweyr.com>
References:  <375707D7.CBE3586B@gta.com> <19990603162104.C8565@tsdev.inktomi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
John Plevyak wrote:
> 
> On Thu, Jun 03, 1999 at 06:55:19PM -0400, Larry Baird wrote:
> > I have found a small problem in nameser.h in the ns_rr structure.
> > This structure has a member named class that causes a compilation
> > problem if you include nameser.h into C++.  I suspect that I may be
> > the only person to ever hit up against this (:.  Any comments before
> > I summit a bug report?
> >
> > --
> > ------------------------------------------------------------------------
> > Larry Baird
> > Global Technology Associates, Inc.  | Orlando, FL
> > Email: lab@gta.com                  | TEL 407-380-0220, FAX 407-380-6080
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> 
> I have hit this 'bug'.   I have a patch:
> 
> Index: include/arpa/nameser.h
> ===================================================================
> RCS file: /usr/cvsroot/src/include/arpa/nameser.h,v
> retrieving revision 1.12
> diff -c -r1.12 nameser.h
> *** nameser.h   1998/06/11 08:55:15     1.12
> --- nameser.h   1999/03/03 18:53:23
> ***************
> *** 140,146 ****
>   typedef       struct __ns_rr {
>         char            name[NS_MAXDNAME];      /* XXX need to malloc */
>         u_int16_t       type;
> !       u_int16_t       class;
>         u_int32_t       ttl;
>         u_int16_t       rdlength;
>         const u_char    *rdata;
> --- 140,146 ----
>   typedef       struct __ns_rr {
>         char            name[NS_MAXDNAME];      /* XXX need to malloc */
>         u_int16_t       type;
> !       u_int16_t       _class;
>         u_int32_t       ttl;
>         u_int16_t       rdlength;
>         const u_char    *rdata;
> ***************
> *** 149,155 ****
>   /* Accessor macros - this is part of the public interface. */
>   #define ns_rr_name(rr)        (((rr).name[0] != '\0') ? (rr).name : ".")
>   #define ns_rr_type(rr)        ((rr).type + 0)
> ! #define ns_rr_class(rr)       ((rr).class + 0)
>   #define ns_rr_ttl(rr) ((rr).ttl + 0)
>   #define ns_rr_rdlen(rr)       ((rr).rdlength + 0)
>   #define ns_rr_rdata(rr)       ((rr).rdata + 0)
> --- 149,155 ----
>   /* Accessor macros - this is part of the public interface. */
>   #define ns_rr_name(rr)        (((rr).name[0] != '\0') ? (rr).name : ".")
>   #define ns_rr_type(rr)        ((rr).type + 0)
> ! #define ns_rr_class(rr)       ((rr)._class + 0)
>   #define ns_rr_ttl(rr) ((rr).ttl + 0)
>   #define ns_rr_rdlen(rr)       ((rr).rdlength + 0)
>   #define ns_rr_rdata(rr)       ((rr).rdata + 0)
> Index: lib/libc/net/ns_parse.c
> ===================================================================
> RCS file: /usr/cvsroot/src/lib/libc/net/ns_parse.c,v
> retrieving revision 1.1
> diff -c -r1.1 ns_parse.c
> *** ns_parse.c  1998/06/11 09:02:40     1.1
> --- ns_parse.c  1999/03/04 19:00:06
> ***************
> *** 160,166 ****
>         NS_GET16(rr->type, handle->_ptr);
>         if (handle->_ptr + NS_INT16SZ > handle->_eom)
>                 goto emsgsize;
> !       NS_GET16(rr->class, handle->_ptr);
>         if (section == ns_s_qd) {
>                 rr->ttl = 0;
>                 rr->rdlength = 0;
> --- 160,166 ----
>         NS_GET16(rr->type, handle->_ptr);
>         if (handle->_ptr + NS_INT16SZ > handle->_eom)
>                 goto emsgsize;
> !       NS_GET16(rr->_class, handle->_ptr);
>         if (section == ns_s_qd) {
>                 rr->ttl = 0;
>                 rr->rdlength = 0;
> 
> I would be appreciative if someone could check this in/fix it in
> some other way.

Sadly, just slapping extern "C" {} around it doesn't help.  Have you 
done a "make world" to see what breaks?  Personally, I don't like the 
_class nomenclature, I'd rather see qclass or something of that sort;
a leading _ generally implies something buried in the bowels of the 
implementation.  I also worry about breaking any ports that use low-
level features of the resolver.

All in all, an ulgy little problem you've brought up here.  ;^)

-- 
       "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                 Softweyr LLC
http://www.softweyr.com/~softweyr                      wes@softweyr.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37577B9F.93DB3DD0>