| Message ID | 20140604025109.GL507@brightrain.aerifal.cx |
|---|---|
| State | New |
| Headers | show |
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).
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
--- 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.