Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Problem in 'packet-f5ethtrailer.c'

From: Guy Harris <gharris@xxxxxxxxx>
Date: Fri, 20 Mar 2020 10:45:22 -0700
On Mar 20, 2020, at 8:09 AM, João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> 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