From mboxrd@z Thu Jan 1 00:00:00 1970 From: scj@yaccman.com (scj@yaccman.com) Date: Wed, 23 Jan 2013 09:49:13 -0800 Subject: [TUHS] History of strncpy In-Reply-To: <12408BE9-5FC8-4ECA-93C1-38D27EF1DA23@ieee.org> References: <5CE5BCC9-06CF-423D-AEBA-636952773EDA@ronnatalie.com> <12408BE9-5FC8-4ECA-93C1-38D27EF1DA23@ieee.org> Message-ID: <0634b28b28366379e2767e9cc43c3e96.squirrel@webmail.yaccman.com> This does indeed bring up memories. The earliest Unix manuals printed data structure definitions (e.g., inode structure) in the manual. Programmers copied these structures into their code. When we ported Unix to 32-bits, this turned out to be a disaster. The whole constellation of header files, etc. was invented to get these declarations out of user code and into a place that could adapt to different machines. The earliest lint programs checked that system calls that passed pointers to structures had not just compatible definitions but got their structure definitions from the same physical location on disc. After several painful weeks, we had cleaned these embedded definitions out of the system and most user code. Something like strncpy must have existed in Unix very early, however. The earliest Unix systems had file names limited to 6 characters (shades of FORTRAN!). If you used a longer name, it was truncated. This led to some nasty traps. You could edit a file "smile.c" and write it out, where it went into the file system as "smile." Repeated edits would continue to work just fine. But when you compiled the sucker, the compiler created the file "smile.o" and wrote it out, where it also entered the file system as "smile." and wiped out the source file!