No, sa_data is a minimum size, not a maximum. For unix domain sockets you should look at the definition of sockaddr_un which has char sun_path[104]; but again, that's a minimum reserved size and if you allocate a larger size you can use sockets with longer names.
And, the 14 character limit in old unix was for individual path components, whereas unix domain sockets contain complete paths, so the 14 character limit was never relevant for unix domain socket addresses.
Likely, but the causality goes the other way. Sockets arrived in 4.2BSD on Sun and VAX, well after the world's attention had moved away from PDP-11 Unix.
Hah! I'd never noticed that it was actually defined that way on many systems (including GNU); POSIX says it should be declared as
char sa_data[];
So thanks for that! However, I don't think your suggestion as to the reasoning passes muster; (1) the socket interface originated in BSD, where longer filenames already existed, and (2) for AF_UNIX sockets, the data is the full path including directories, not just the base filename.
My guess is that sockaddr was originally defined as 16 bytes (2 bytes type, 14 bytes data) just because someone thought it was a nice round number, and that GNU and other systems have kept the "14" to establish a minimum size for the struct, and that in order to avoid breaking historical code that uses sockaddr instead of sockaddr_storage.
And we have a better clue as to why: there was a separate "sockaddri" that allowed for indirect references for address sizes > 14 bytes.
So the sa_data[14] comes from 16 bytes being the maximum amount of data that Bill Joy was willing to pass around by value instead of by reference.
(Actually, that was probably modeled after the older `struct in_addr`, but the headers for that are missing--so I can't tell. Perhaps it was a design decision carried forward from someone else; perhaps someone from BBN?)
