The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com (scj@yaccman.com)
Subject: [TUHS] History of strncpy
Date: Wed, 23 Jan 2013 09:49:13 -0800	[thread overview]
Message-ID: <0634b28b28366379e2767e9cc43c3e96.squirrel@webmail.yaccman.com> (raw)
In-Reply-To: <12408BE9-5FC8-4ECA-93C1-38D27EF1DA23@ieee.org>

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!




  reply	other threads:[~2013-01-23 17:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23  4:03 Nevin Liber
2013-01-23  4:41 ` Warren Toomey
2013-01-23  4:58 ` Warner Losh
2013-01-23 14:16 ` Clem Cole
2013-01-23 15:01   ` Ronald Natalie
2013-01-23 15:24     ` Armando Stettner
2013-01-23 17:49       ` scj [this message]
2013-01-23 18:19       ` Ronald Natalie
2013-01-23 19:33         ` Ronald Natalie
2013-01-23 19:59           ` Clem Cole
2013-01-23 22:43     ` Mary Ann Horton
2013-01-24  0:01       ` Clem Cole
2013-01-24  0:37 ` Jonathan Gevaryahu
2013-01-23 17:56 Michael Spacefalcon
2013-01-23 21:08 ` Larry McVoy
2013-01-23 21:39 ` Ronald Natalie
2013-01-23 21:46   ` John Cowan
2013-01-24  6:02     ` Larry McVoy
2013-01-24  6:34       ` Steve Nickolas
2013-01-24 14:42       ` Ronald Natalie
2013-01-24 14:52         ` Warner Losh
2013-01-24 16:01           ` Ronald Natalie
2013-01-24 18:31             ` Tom Ivar Helbekkmo
2013-01-25  2:06               ` Warner Losh
2013-01-24 16:21           ` Clem Cole
2013-02-01  0:28             ` Larry McVoy
2013-01-31 23:52           ` Random832
2013-02-01  0:06             ` Warner Losh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0634b28b28366379e2767e9cc43c3e96.squirrel@webmail.yaccman.com \
    --to=scj@yaccman.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).