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: [email protected] | TEL 407-380-0220, FAX 407-380-6080
> >
> >
> > To Unsubscribe: send mail to [email protected]
> > 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 [email protected]
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-hackers" in the body of the message
