Please address NI_NUMERICSCOPE issue
diff mbox

Message ID 20140604025109.GL507@brightrain.aerifal.cx
State New
Headers show

Commit Message

Rich Felker June 4, 2014, 2:51 a.m. UTC
On Sun, Oct 14, 2012 at 06:06:43PM -0400, Rich Felker wrote:
> See bug #14102: http://sourceware.org/bugzilla/show_bug.cgi?id=14102
> 
> Even if nobody is willing to add the functionality immediately, can we
> at least agree on a value it will have when it's added?

This issue is really trivial and I've been waiting for someone to
address it for almost 2 years now. Is the attached patch acceptable?

Rich

Comments

Joseph Myers June 19, 2014, 10:13 p.m. UTC | #1
On Tue, 3 Jun 2014, Rich Felker wrote:

> On Sun, Oct 14, 2012 at 06:06:43PM -0400, Rich Felker wrote:
> > See bug #14102: http://sourceware.org/bugzilla/show_bug.cgi?id=14102
> > 
> > Even if nobody is willing to add the functionality immediately, can we
> > at least agree on a value it will have when it's added?
> 
> This issue is really trivial and I've been waiting for someone to
> address it for almost 2 years now. Is the attached patch acceptable?

You need to explain why you think ignoring the flag is a valid 
implementation (or that defining it without implementing it is more 
helpful to applications, or better accords with established glibc 
conventions, than not defining it until there is an implementation).
Rich Felker June 20, 2014, 12:52 a.m. UTC | #2
On Thu, Jun 19, 2014 at 10:13:11PM +0000, Joseph S. Myers wrote:
> On Tue, 3 Jun 2014, Rich Felker wrote:
> 
> > On Sun, Oct 14, 2012 at 06:06:43PM -0400, Rich Felker wrote:
> > > See bug #14102: http://sourceware.org/bugzilla/show_bug.cgi?id=14102
> > > 
> > > Even if nobody is willing to add the functionality immediately, can we
> > > at least agree on a value it will have when it's added?
> > 
> > This issue is really trivial and I've been waiting for someone to
> > address it for almost 2 years now. Is the attached patch acceptable?
> 
> You need to explain why you think ignoring the flag is a valid 
> implementation (or that defining it without implementing it is more 
> helpful to applications, or better accords with established glibc 
> conventions, than not defining it until there is an implementation).

After looking at the code recently, I think I'm actually mistaken in
claiming that it would be a nop. IMO this makes it a more serious
omission since it's impossible to get output in the standard numeric
form. I can look into what would be involved in implementing it;
hopefully it's just a single conditional, but it might be worse if
flags don't get propagated all the way down to the code that needs to
check them.

For now can we at least agree than, when this omission is fixed in
glibc, NI_NUMERICSCOPE will have the value 256 (presently the next
unused bit)? I've already implemented it in musl with that value and
would like to keep the interface as compatible as possible.

Rich

Patch
diff mbox

--- resolv/netdb.h.orig	2014-06-03 22:58:26.000000000 -0400
+++ resolv/netdb.h	2014-06-03 23:00:06.000000000 -0400
@@ -653,6 +653,7 @@ 
 #  define NI_IDN_USE_STD3_ASCII_RULES 128 /* Validate strings according to
 					     STD3 rules.  */
 # endif
+# define NI_NUMERICSCOPE	256	/* Don't convert scope_id to name.  */
 
 /* Translate name of a service location and/or a service name to set of
    socket addresses.