This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.0: getnameinfo bug

On Thu, Aug 6, 2009 at 8:48 AM, Zhiming Zhou wrote:
> This bug happens on every 1.7.0 beta version.
> I use getnameinfo function with NI_NUMERICHOST flag,

I assume that it works if you pass NI_NUMERICSERV (returning e.g. "21"
instead of "ftp" in that case).

According to the RFC (2553), the specific behavior here is not defined:

   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
   located in the DNS, the numeric form of the host's address is returned
   instead of its name (e.g., by calling inet_ntop() instead of
   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
   returned if the host's name cannot be located in the DNS.

   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
   address is returned (e.g., its port number) instead of its name.  The
   two NI_NUMERICxxx flags are required to support the "-n" flag that
   many commands provide.

The Linux version of the function treats services and hosts alike in
this regard, but the critical bit of the spec ("or if the host's name
cannot be located in the DNS") does not have a parallel in the
description of the behavior with regard to services.   This difference
is reinforced by the fact that NI_NAMEREQD is only stated to affect
hostname resolution, and there's no corresponding "service name
required" flag.

So it appears that the Cygwin behavior is POSIXly correct, but perhaps
behaving more like Linux in this regard is desirable.

Mark J. Reed <>

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]