0000952: Byte order for INADDR_* - Austin Group Defect Tracker

Notes
(0002711) shware_systems (reporter) 2015-06-13 23:04 edited on: 2015-06-13 23:05	RFC 791, Appendix B, specifies big endian shall be used in transmitting source and destination addresses as part of internet packet headers, whether host byte order is big or little endian. It uses 'most-significant-octet of multi-octet field' as the language, but it isn't neutral. Clarification in_addr_t is a symbolic simplification of the physical bit-fields comprising an IPv4 (net_id, host_id) union may be useful, but this change is not warranted, imo.

(0002712) dannyniu (reporter) 2015-06-14 07:04 edited on: 2015-06-14 07:07	Perhaps I didn't say well. What I want was that the standard clarify, that one should htonl() the INADDR_* constants before assigning them to .sin_addr.s_addr. And when I mean "neutral", I actually meant htonl() or not wouldn't matter for INADDR_ANY and INADDR_BROADCAST since they're same in either order.

(0002713) geoffclare (manager) 2015-06-15 09:03	Since the only INADDR_* constants defined in the standard are byte-order-neutral ones, it doesn't make any sense for the normative text to require them to be defined in host byte order. I think the best we can do is add something to the RATIONALE section explaining that if the implementation defines any additional INADDR_* constants that do not have byte-order-neutral values, then they should be defined in host byte order. There are some additional problems with INADDR_ANY. The standard says it is used as a destination address for connect(), sendmsg(), and sendto(), and calls it the "IPv4 local host address". I believe it should instead say that it is used with bind() and call it the "IPv4 wildcard address".

(0002714) shware_systems (reporter) 2015-06-15 14:26	Re: note 2712: Yes, I was confused a bit there, INADDR_LOOPBACK being just an int. Re: note 2713: Additionally, to be used directly the identifiers must be defined as something like: static const sockaddr_in const_ANY = {AF_INET, 0, ANY_ADDR}; extern sockaddr INADDR_ANY = &(sockaddr) const_ANY; so sendto(... , INADDR_ANY, sizeof sockaddr_in); can be used, as destination is a (sockaddr ) type. LSB using the INADDR_ prefix for another data type, while still conforming, is where confusion stems from it looks. ANY_ADDR above is where byte ordering becomes an issue, for other _ADDR type addresses; e.g. LOOP_ADDR would be 0x0100007F on a little endian host. If anything, it's the LSB docs that need tweaking to explain that identifier isn't usable as is for a destination parameter as the ones provided by the standard are. I read those interfaces as when INADDR_ANY is provided, they are supposed to call bind() internally with the first not-in-use address, possibly discovered via procedures like DHCP negotiation. I read bind() more as for static addressing setups, where the application knows the address it should be bound to beforehand, or has been assigned by DHCP, and INADDR_ANY not appropriate then. Unless I've missed something, changing the text so its use with bind() is specified will break various implementations. Normatively, I think line 10269 should be changed from: The <netinet/in.h> header shall define the following symbolic constants for use as destination addresses for connect(), sendmsg(), and sendto(): to: The <netinet/in.h> header shall define the following symbolic constants for use as initializers of the destination parameter for connect() and sendto(), and of the msghdr.msg_name value for the address parameter to sendmsg(): to reflect void msg_name a generic sockaddr msg_name in usage, and in usage a specific port may have to be set in those arguments, for service discovery usages.

(0002751) geoffclare (manager) 2015-07-09 16:31	On page 307 line 10269, change from: The <netinet/in.h> header shall define the following symbolic constants for use as destination addresses for connect(), sendmsg(), and sendto(): INADDR_ANY IPv4 local host address. INADDR_BROADCAST IPv4 broadcast address. to: The <netinet/in.h> header shall define the following symbolic constant for use as a local address in the structure passed to bind(): INADDR_ANY IPv4 wildcard address. The <netinet/in.h> header shall define the following symbolic constant for use as a destination address in the structures passed to connect(), sendmsg(), and sendto(): INADDR_BROADCAST IPv4 broadcast address. On page 309 line 10325 (netinet/in.h RATIONALE), change from: None. to: The INADDR_ANY and INADDR_BROADCAST values are byte-order-neutral and thus their byte order is not specified. Many implementations have additional constants as extensions, such as INADDR_LOOPBACK, that are not byte-order-neutral. Traditionally, these constants are in host byte order, requiring the use of htonl() when using them in a sockaddr_in structure.

Issue History
Date Modified	Username	Field	Change
2015-06-02 03:58	dannyniu	New Issue
2015-06-02 03:58	dannyniu	Name	=> DannyNiu/NJF
2015-06-02 03:58	dannyniu	Section	=> netinet/in.h - Internet address family
2015-06-02 03:58	dannyniu	Page Number	=> 307
2015-06-02 03:58	dannyniu	Line Number	=> 10269
2015-06-13 23:04	shware_systems	Note Added: 0002711
2015-06-13 23:05	shware_systems	Note Edited: 0002711
2015-06-14 07:04	dannyniu	Note Added: 0002712
2015-06-14 07:07	dannyniu	Note Edited: 0002712
2015-06-15 09:03	geoffclare	Note Added: 0002713
2015-06-15 14:26	shware_systems	Note Added: 0002714
2015-07-09 16:31	geoffclare	Note Added: 0002751
2015-07-09 16:32	geoffclare	Interp Status	=> ---
2015-07-09 16:32	geoffclare	Final Accepted Text	=> Note: 0002751
2015-07-09 16:32	geoffclare	Status	New => Resolved
2015-07-09 16:32	geoffclare	Resolution	Open => Accepted As Marked
2015-07-12 08:51	geoffclare	Tag Attached: tc2-2008
2019-06-10 08:54	agadmin	Status	Resolved => Closed

Relationships

Aardvark Mark IV