On 20/03/20 17:45, Guy Harris wrote:
On Mar 20, 2020, at 8:09 AM, João Valverde <joao.valve...@tecnico.ulisboa.pt> 
wrote:

On 19/03/20 18:38, Guy Harris wrote:

This isn't unique to Windows.  It dates back to old BSD, in which struct in_addr 
contained a union of multiple different types for an IP address, with some types being 
structures breaking up the address into host and network bits, and even included bits for 
IMP numbers.  s_addr was defined to be the member of the union that just defined an 
address as a 32-bit integer, so if you referred to the s_addr "field" of the 
structure it gave you the 32-bit integer value.
Because POSIX defines struct in_addr as an opaque structure with an s_addr element, some 
BSD Socket implementations get creative with the use of unions and use a macro definition 
for "s_addr", which is terribly bad practice and a tremendously ugly botch.
One such implementation was in an obscure OS called "4.2BSD":

        
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/netinet/in.h

4.2BSD came out in 1982, and the first version of POSIX came out in 1988 - and, as I remember, it 
had no networking APIs in it - so you can't says "they did that because POSIX let them do 
that".  It's more like "POSIX allows that because some UN*Xes didn't discard that 
4.2BSDism".

And the general idea of using unions to overlay a 32-bit integer version of an 
IP address and various structure versions showing pre-CIDR divisions of IP 
addresses dates back to the BBN TCP/IP:

        https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/bbnnet/net.h

Interesting bit of archeology. You're right that the practice predates POSIX with the BSDs. The point is that the inevitable name collisions are an obvious botch.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Reply via email to