| Summary: | libXmu not IPv6 clean | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Mike A. Harris <mharris> |
| Component: | Lib/Xmu | Assignee: | Jeremy Huddleston Sequoia <jeremyhu> |
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | jeremyhu, matthieu.herrb |
| Version: | 7.1 (2006.05) | Keywords: | love |
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | 2011BRB_Reviewed IPv6 | ||
| i915 platform: | i915 features: | ||
libXmu was never updated for IPv6. Does anything actually use this function with XA_IP_ADDRESS? (In reply to comment #1) > libXmu was never updated for IPv6. > > Does anything actually use this function with XA_IP_ADDRESS? No idea... It was discovered during a Red Hat audit of the entire Fedora Core OS for missing IPv6 support. Will this be fixed in a future release? It should be trivial to fix, but I don't know if that should be by modifying the XA_IP_ADDRESS target or adding a new XA_IP6_ADDRESS - will existing callers be broken if XA_IP_ADDRESS returns a different address type/length than they expect? (In reply to comment #3) > It should be trivial to fix, but I don't know if that should be by modifying > the XA_IP_ADDRESS target or adding a new XA_IP6_ADDRESS - will existing callers > be broken if XA_IP_ADDRESS returns a different address type/length than they > expect? Hard to say without knowing every application out there and having its source code and testing it I guess. A solution which is transparent as possible would be best IMHO, so the former solution above seems best to me. Another option is to leave it broken until an actual real world bug is reported about it, so there is a real test case to go by. Yeah, but I was unable to find even one application using it - google only finds references to libXmu when searching for XA_IP_ADDRESS. Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. Yick. This should get fixed. https://www.google.com/codesearch#search/&q=XA_IP_ADDRESS&sq=&type=cs still finds almost nothing referencing XA_IP_ADDRESS other than copies of libXmu itself. Adjusting priority given Alan's comment. Thanks. Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
XmuConvertStandardSelection() in CvtStdSel.c contains the following code snippet: #if defined(TCPCONN) if (*target == XA_IP_ADDRESS(d)) { char hostname[1024]; #ifdef XTHREADS_NEEDS_BYNAMEPARAMS _Xgethostbynameparams hparams; #endif struct hostent *hostp; hostname[0] = '\0'; (void) XmuGetHostname (hostname, sizeof hostname); if ((hostp = _XGethostbyname (hostname,hparams)) == NULL) return False; if (hostp->h_addrtype != AF_INET) return False; *length = hostp->h_length; *value = XtMalloc(*length); (void) memmove (*value, hostp->h_addr, *length); *type = XA_NET_ADDRESS(d); *format = 8; return True; } #endif This code does not appear that it would function correctly with IPv6. Closer inspection of libXmu code appears that it has never been updated for IPv6. There is a --enable-IPv6 flag on ./configure, but it doesn't actually do anything when used. Did IPv6 support fall out somewhere along the line, or was libXmu never updated for IPv6 support?