Hello list,
I notice the following in socketsh.inc:

  TInetSockAddr = packed Record
    case boolean of
     false : (
  {$ifdef SOCK_HAS_SINLEN}
     sin_len     : cuchar;
  {$endif}
     sin_family  : sa_family_t;
     sin_port    : cushort;
     sin_addr    : in_addr;
     xpad         : array [0..7] of char; { to get to the size of sockaddr... }
      );
   true: (
  {$ifdef SOCK_HAS_SINLEN}
     len     : cuchar;
  {$endif}
     family  : sa_family_t;
     port    : cushort;
     addr    : cardinal;
     pad         : array [0..7] of char; { to get to the size of sockaddr... }
      );
    end;

Note that this structure differs in field names (sin_ omited in 2nd case) and that field
addr : cardinal <--> sin_addr : in_addr differs in type. Types cardinal and in_addr are compatible as far as I can see.

From Delphi help:

type
TShapeList = (Rectangle, Triangle, Circle, Ellipse, Other);
TFigure = record
 case TShapeList of
  Rectangle: (Height, Width: Real);
  Triangle: (Side1, Side2, Angle: Real);
  Circle: (Radius: Real);
  Ellipse, Other: ();
end;

For each record instance, the compiler allocates enough memory to hold all the fields in the largest variant. The optional tag and the constantLists (like Rectangle, Triangle, and so forth in the last example) play no role in the way the compiler manages the fields; they are there only for the convenience of the programmer.

All fields exist simultaneously.
Why there are same fields with different names? Isn't this just duplicating code?

I have tried working with sockets using either of the fields (with or without sin_ prefix) and of course it works? Why is it there I am wondering?

Greetings Alexander.

I have tried working with sockets using either of the fields (with or without sin_ prefix) and of course it works? Why is it there I am wondering?

Compatibility: e.g. posix and delphi might use different names for the fields. So the unit supports posix as well as delphi style naming.

... this mostly to enable easy conversion of *nix C examples. This was one of the lessons of the 1.0.x RTL, a non systematic naming really complicates converting examples/code.

So the few renames that are still there (like the fp* prefix of functions and always having p<x> and t<x>) are systematic.