[TUHS] History of strncpy

[TUHS] History of strncpy

[Michael Spacefalcon]

Ronald Natalie <ron at ronnatalie.com> wrote:

> I suspect strcpy arrived with the "portable I/O library", an abomination
> that eventually evolved into the stdio library and to this day is still
> stinking up the standard C language.

What's so bad about stdio?  That's a genuine question - I've never had
a reason to dislike stdio...

SF

[TUHS] History of strncpy

[Larry McVoy]

On Wed, Jan 23, 2013 at 05:56:14PM +0000, Michael Spacefalcon wrote:
> Ronald Natalie <ron at ronnatalie.com> wrote:
> > I suspect strcpy arrived with the "portable I/O library", an abomination
> > that eventually evolved into the stdio library and to this day is still
> > stinking up the standard C language.
> 
> What's so bad about stdio?  That's a genuine question - I've never had
> a reason to dislike stdio...

Well, there are little incompats that make cross platform unpleasant.
We (bitkeeper source management guys) gave up and imported the NetBSD
stdio library and ship that.  Which did enable some fun enhancements.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] History of strncpy

[Ronald Natalie]

It's really in my mind the opposite of C and unix in design.    It's not very consistent.   Why does the FILE
structure go as the first argument in some functions (similar to the way UNIX tends to do things) and at the end of others?
Why on earth did they preserve the silly fread/fwrite size feature that just multiplies the two middle args together long
after it was realized that portability doesn't demand making such a distinction.   Why is there no consistency in
return values?    It's was poorly thought out as the portable I/O library (which apparently never really got ported\
anywhere) and just condified in all it's ugliness.

On Jan 23, 2013, at 12:56 PM, Michael Spacefalcon wrote:

> Ronald Natalie <ron at ronnatalie.com> wrote:
> 
>> I suspect strcpy arrived with the "portable I/O library", an abomination
>> that eventually evolved into the stdio library and to this day is still
>> stinking up the standard C language.
> 
> What's so bad about stdio?  That's a genuine question - I've never had
> a reason to dislike stdio...
> 
> SF
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] History of strncpy

[John Cowan]

Ronald Natalie scripsit:

> Why does the FILE structure go as the first argument in some functions
> (similar to the way UNIX tends to do things) and at the end of others?

I think it goes at the end in every case except for varargs functions,
where we wouldn't be able to know which one was last easily.

> Why on earth did they preserve the silly fread/fwrite size feature
> that just multiplies the two middle args together long after it was
> realized that portability doesn't demand making such a distinction.

I like the idea: essentially it's about reading or writing an array
of a specified type.

-- 
John Cowan  cowan at ccil.org    http://ccil.org/~cowan
No man is an island, entire of itself; every man is a piece of the
continent, a part of the main.  If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friends or of thine own were: any man's death diminishes me,
because I am involved in mankind, and therefore never send to know for
whom the bell tolls; it tolls for thee.  --John Donne

[TUHS] History of strncpy

[Larry McVoy]

On Wed, Jan 23, 2013 at 04:46:51PM -0500, John Cowan wrote:
> Ronald Natalie scripsit:
> > Why on earth did they preserve the silly fread/fwrite size feature
> > that just multiplies the two middle args together long after it was
> > realized that portability doesn't demand making such a distinction.
> 
> I like the idea: essentially it's about reading or writing an array
> of a specified type.

As a SPARC guy (in the past), I think it may have had something to do 
about alignment.

That said, I hate the fread/fwrite interfaces.  We're fixing them in 
our stdio.  freadn(f, buf, n).
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] History of strncpy

[Steve Nickolas]

On Wed, 23 Jan 2013, Larry McVoy wrote:

> On Wed, Jan 23, 2013 at 04:46:51PM -0500, John Cowan wrote:
>> Ronald Natalie scripsit:
>>> Why on earth did they preserve the silly fread/fwrite size feature
>>> that just multiplies the two middle args together long after it was
>>> realized that portability doesn't demand making such a distinction.
>>
>> I like the idea: essentially it's about reading or writing an array
>> of a specified type.
>
> As a SPARC guy (in the past), I think it may have had something to do
> about alignment.
>
> That said, I hate the fread/fwrite interfaces.  We're fixing them in
> our stdio.  freadn(f, buf, n).
>

That syntax makes sense.  Though you'd prolly need a "#define 
fread(b,s,n,f) freadn(f,b,((s)*(n)))", right?  For backward compatibility.

[TUHS] History of strncpy

[Ronald Natalie]

On Jan 24, 2013, at 1:02 AM, Larry McVo
> As a SPARC guy (in the past), I think it may have had something to do 
> about alignment.
> 
> That said, I hate the fread/fwrite interfaces.  We're fixing them in 
> our stdio.  freadn(f, buf, n).
> 
Amen.    For practical matters, there is no way given the rest of the library that an implementation can do
anything other than multiply the two middle args together.    The stream still needs to be a byte stream
and passing things as void* sort of divorces any clue as to what alignment or other portability requirements
are (and I've worked on C on some rather odd word sized machines like 36 and 60 as well as machines
that encode the word size in the pointer... believe me there were TONS of bugs in 4BSD with regard to that
one where they would stuff a char* into a union and retrieve it with a int* thwarting any possible conversion
(as we put in place when you casted one pointer to other).

It's not true that FILE went at the end, except in vararg'd functions.   It goes at the beginning of ftell (which
mimics the UNIX  tell call).    As with Larry, I'd much perferred they mimic'd most of the UNIX calls when
possible.   They were reasonably thought out.

[TUHS] History of strncpy

[Warner Losh]

On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:

> 
> On Jan 24, 2013, at 1:02 AM, Larry McVo
>> As a SPARC guy (in the past), I think it may have had something to do 
>> about alignment.
>> 
>> That said, I hate the fread/fwrite interfaces.  We're fixing them in 
>> our stdio.  freadn(f, buf, n).
>> 
> Amen.    For practical matters, there is no way given the rest of the library that an implementation can do
> anything other than multiply the two middle args together.    The stream still needs to be a byte stream
> and passing things as void* sort of divorces any clue as to what alignment or other portability requirements
> are (and I've worked on C on some rather odd word sized machines like 36 and 60 as well as machines
> that encode the word size in the pointer... believe me there were TONS of bugs in 4BSD with regard to that
> one where they would stuff a char* into a union and retrieve it with a int* thwarting any possible conversion
> (as we put in place when you casted one pointer to other).

Historically the only implementation I know that didn't just multiply the two args together was on VAX/VMS's VAXC. The underlying filesystem had a notion of a file of records, so you'd get very different result from n * size, 1 and n, size. The former would produce one record that was n * size, while the latter would produce n records, each of which was size in length. As with all things on that compiler, this was only sometimes, and it greatly depended on how the file was created... Mostly a royal pain, except in some very rare instances where it was what you wanted to happen.

Warner

> It's not true that FILE went at the end, except in vararg'd functions.   It goes at the beginning of ftell (which
> mimics the UNIX  tell call).    As with Larry, I'd much perferred they mimic'd most of the UNIX calls when
> possible.   They were reasonably thought out.
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] History of strncpy

[Ronald Natalie]

Ah yes, VAX C.   You're right about that one.   It had a completing different internal implementation of the FILE
struct.    While I supervised a team of VAX VMS programmers, that's one of the platforms I never dabbled in directly.

[TUHS] History of strncpy

[Tom Ivar Helbekkmo]

Ronald Natalie <ron at ronnatalie.com> writes:

> Ah yes, VAX C.  You're right about that one.  It had a completing
> different internal implementation of the FILE struct.  While I
> supervised a team of VAX VMS programmers, that's one of the platforms
> I never dabbled in directly.

I ported C-TeX to VAX/VMS many years ago, and got a huge performance
increase when I swapped the built-in FILE interface to RMS stream files
for one I wrote myself, which explicitly did block I/O on RMS binary
files instead.  That was a fun project.  :)

-tih
-- 
It doesn't matter how beautiful your theory is, it doesn't matter how smart
you are. If it doesn't agree with experiment, it's wrong.  -Richard Feynman

[TUHS] History of strncpy

[Warner Losh]

On Jan 24, 2013, at 11:31 AM, Tom Ivar Helbekkmo wrote:

> Ronald Natalie <ron at ronnatalie.com> writes:
> 
>> Ah yes, VAX C.  You're right about that one.  It had a completing
>> different internal implementation of the FILE struct.  While I
>> supervised a team of VAX VMS programmers, that's one of the platforms
>> I never dabbled in directly.
> 
> I ported C-TeX to VAX/VMS many years ago, and got a huge performance
> increase when I swapped the built-in FILE interface to RMS stream files
> for one I wrote myself, which explicitly did block I/O on RMS binary
> files instead.  That was a fun project.  :)

TeX was one of the programs I was thinking of. GNU Emacs was another... I ported about a dozen different unix programs back in the day, and had to put lots of different hacks in...  The C FILE interface definitely was somewhat suboptimal...

Warner

[TUHS] History of strncpy

[Clem Cole]

Right on..

Funny, just last week I got into an argument with a VMS person defending
Culter's RMS on a DEC mailing list.
Here at Intel in NH, many of the old DEC compiler guys still work in the
building (and still hack on a FTN compiler to run codes on systems we are
still creating).   Since, I often eat lunch with them, I just did a little
research on the fact from that compiler to verify what I thought I
remembered.

So I had laughed that you mention that Culter's compiler could on certain
cases support RMS.  Please remember that it was C and that compiler that
forced him to add stream I/O to VMS.   As time went on, many ( ?most? ) VMS
developers (including the FTN team) stopped using the RMS library and
started to use stream since it was >>so<< much easier.

To dmr's credit at the time of stdio, record I/O was popular on
"enterprise" class systems - ney  mainframes of IBM and BUNCH companies.
 Which is why VMS's I/O system was record based - DEC wanted a piece of
that action (and got it).   The Multics family widely used the idea of a
byte stream and not needing some sort of "facility" or "record" system to
do the work; but at the time it was not clear which would "win."

So the fact that Dennis was trying to provide an interface that could work
on those machines, is again not surprising.  I wonder what things todays
engineers will get crapped on because it was not clear at the time which
way things would go.

Clem

BTW, I 100% agree that the inconsistency of the interfaces, return codes
sins et al, certainly have damaged us.   But then again, who knew?   Other
systems (like VMS) which were much more consistent, but were not as
flexible or "open" died, while C, FORTRAN and UNIX live on.






On Thu, Jan 24, 2013 at 9:52 AM, Warner Losh <imp at bsdimp.com> wrote:

>
> On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
>
> >
> > On Jan 24, 2013, at 1:02 AM, Larry McVo
> >> As a SPARC guy (in the past), I think it may have had something to do
> >> about alignment.
> >>
> >> That said, I hate the fread/fwrite interfaces.  We're fixing them in
> >> our stdio.  freadn(f, buf, n).
> >>
> > Amen.    For practical matters, there is no way given the rest of the
> library that an implementation can do
> > anything other than multiply the two middle args together.    The stream
> still needs to be a byte stream
> > and passing things as void* sort of divorces any clue as to what
> alignment or other portability requirements
> > are (and I've worked on C on some rather odd word sized machines like 36
> and 60 as well as machines
> > that encode the word size in the pointer... believe me there were TONS
> of bugs in 4BSD with regard to that
> > one where they would stuff a char* into a union and retrieve it with a
> int* thwarting any possible conversion
> > (as we put in place when you casted one pointer to other).
>
> Historically the only implementation I know that didn't just multiply the
> two args together was on VAX/VMS's VAXC. The underlying filesystem had a
> notion of a file of records, so you'd get very different result from n *
> size, 1 and n, size. The former would produce one record that was n * size,
> while the latter would produce n records, each of which was size in length.
> As with all things on that compiler, this was only sometimes, and it
> greatly depended on how the file was created... Mostly a royal pain, except
> in some very rare instances where it was what you wanted to happen.
>
> Warner
>
> > It's not true that FILE went at the end, except in vararg'd functions.
> It goes at the beginning of ftell (which
> > mimics the UNIX  tell call).    As with Larry, I'd much perferred they
> mimic'd most of the UNIX calls when
> > possible.   They were reasonably thought out.
> >
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130124/b82df22d/attachment.html>

[TUHS] History of strncpy

[Larry McVoy]

On Thu, Jan 24, 2013 at 11:21:36AM -0500, Clem Cole wrote:
> BTW, I 100% agree that the inconsistency of the interfaces, return codes
> sins et al, certainly have damaged us.   But then again, who knew?   Other
> systems (like VMS) which were much more consistent, but were not as
> flexible or "open" died, while C, FORTRAN and UNIX live on.

What we have done, as I think I mentioned, is include NetBSD's stdio in
our product.  Our libc.a is 1.9MB and it includes stdio, a stacking
file system layer, associative arrays, lz4, my version of Oz's sdbm 
that I changed to use mmap so you could read/write in place, Oz's
regex, all the string functions, the tcp layer from LMbench, zlib,
our utility functions including stacking stdio layers that provide
transparent CRC's over the data, transparent compression (both
zlib and lz4), and a paging layer.

All that crud in 1.9MB unstripped.

Personally, I think that stdio ought to evolve, it's really useful but
I don't think people have pushed it hard enough.  You can do some pretty
neat stuff with it if you work a little.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[TUHS] History of strncpy

[Random832]

On 1/24/2013 9:52 AM, Warner Losh wrote:
> On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
>> Amen. For practical matters, there is no way given the rest of the 
>> library that an implementation can do anything other than multiply 
>> the two middle args together. 


Is there any part of the rest of the library that will be broken if it 
does something like call (e.g. on UNIX) fflush (or _flsbuf), fileno, and 
write in a loop?

vfprintf doesn't call fwrite, so it won't break sprintf.

In theory all I can even think of is if some piece of userspace code 
made assumptions about the state of a setvbuf buffer.

> Historically the only implementation I know that didn't just multiply the two args together was on VAX/VMS's VAXC. The underlying filesystem had a notion of a file of records, so you'd get very different result from n * size, 1 and n, size.

You might get a different result in terms of the resulting underlying 
file, and maybe in terms of performance, but given the requirements the 
standard puts on fread (which I don't imagine it would do if a 
then-prominent implementation violated them), I have to wonder what 
would happen, if this is the case, if you attempted to call fread when 
the file pointer is positioned on a different sized record, or in the 
middle of a record.

Because for all the concessions to non-unix-like file systems the 
standard _does_ make (binary files may be padded with extra zero bytes 
[because they may not be able to be an arbitrary size], text files may 
have a maximum line length and may not be able to contain some control 
characters, heck, _everything_ the standard says about text files is 
non-unix-like), it's IIRC rather strict about "fread has equivalent 
results to getc in a loop".

[TUHS] History of strncpy

[Warner Losh]

On Jan 31, 2013, at 4:52 PM, Random832 wrote:

> On 1/24/2013 9:52 AM, Warner Losh wrote:
>> On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
>>> Amen. For practical matters, there is no way given the rest of the library that an implementation can do anything other than multiply the two middle args together. 
> 
> 
> Is there any part of the rest of the library that will be broken if it does something like call (e.g. on UNIX) fflush (or _flsbuf), fileno, and write in a loop?
> 
> vfprintf doesn't call fwrite, so it won't break sprintf.
> 
> In theory all I can even think of is if some piece of userspace code made assumptions about the state of a setvbuf buffer.
> 
>> Historically the only implementation I know that didn't just multiply the two args together was on VAX/VMS's VAXC. The underlying filesystem had a notion of a file of records, so you'd get very different result from n * size, 1 and n, size.
> 
> You might get a different result in terms of the resulting underlying file, and maybe in terms of performance, but given the requirements the standard puts on fread (which I don't imagine it would do if a then-prominent implementation violated them), I have to wonder what would happen, if this is the case, if you attempted to call fread when the file pointer is positioned on a different sized record, or in the middle of a record.

VAXC would crash and burn, signaling your programming error if you dared try to do this.

> Because for all the concessions to non-unix-like file systems the standard _does_ make (binary files may be padded with extra zero bytes [because they may not be able to be an arbitrary size], text files may have a maximum line length and may not be able to contain some control characters, heck, _everything_ the standard says about text files is non-unix-like), it's IIRC rather strict about "fread has equivalent results to getc in a loop".

The standard makes no such requirements on non-standard files. This behavior had to be explicitly asked for using non-standard cards/args to open, iirc. However, I think early versions of VAX C didn't allow a choice and often you'd find you couldn't do things with files you thought you should be able to. I do believe later versions fixed this to be more standards conforming, but it was quite a shock to get this behavior when I first ran into it.

Then again, VAX C wasn't completely standards compliant for most of the time I used it in college.

Warner

[TUHS] History of strncpy

[Nevin Liber]

On another list I am on, a discussion about the history and purpose of
strncpy has arisen.  The only reference I have found to it is <
http://lwn.net/Articles/507432/>:

The original reason for strncpy() was when directory names were limited to
14 chars. The other two bytes contained the inode number. For that
particular case, strncpy() worked quite well.

Is that really the reason it came into being?

Just a bit curious,
-- 
 Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  (847) 691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130122/95c97f5e/attachment.html>

[TUHS] History of strncpy

[Warren Toomey]

On Tue, Jan 22, 2013 at 10:03:54PM -0600, Nevin Liber wrote:
>   The original reason for strncpy() was when directory names were limited to
>   14 chars. The other two bytes contained the inode number. For that
>   particular case, strncpy() worked quite well.
> 
> Is that really the reason it came into being?

strncpy() was introduced in 7th Edition Unix. From a quick perusal through
the V7 source code, these files used strncpy():

usr/src/cmd/ranlib.c		strncpy(firstname, arp.ar_name, 14);
usr/src/cmd/login.c		#define SCPYN(a, b) strncpy(a, b, sizeof(a))
usr/src/cmd/expr.y		strncpy(Mstring[0], p, num);
usr/src/cmd/atrun.c		strncpy(file, dirent.d_name, DIRSIZ);
usr/src/cmd/ed.c		strncpy(buf, keyp, 8);
usr/src/cmd/mkdir.c		strncpy(pname, d, slash);
usr/src/cmd/xsend/lib.c		strncpy(buf, s, 10);
usr/src/cmd/crypt.c		strncpy(buf, pw, 8);

Only two of these (ranlib.c and atrun.c) appear to be specifically related
to the 14-byte filename limit in V7. So I'd say that strncpy() wasn't
introduced solely to deal with 14-byte filenames.

Cheers,
	Warren

[TUHS] History of strncpy

[Warner Losh]

A quick search of the archive shows that it appears, with strcpy, in v7, which suggests that this isn't the only reason...

Warner
On Jan 22, 2013, at 9:03 PM, Nevin Liber wrote:

> On another list I am on, a discussion about the history and purpose of strncpy has arisen.  The only reference I have found to it is <http://lwn.net/Articles/507432/>:
> 
> The original reason for strncpy() was when directory names were limited to 14 chars. The other two bytes contained the inode number. For that particular case, strncpy() worked quite well.
> 
> Is that really the reason it came into being?
> 
> Just a bit curious,
> -- 
>  Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  (847) 691-1404
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] History of strncpy

[Clem Cole]

Nevin/Warren,

RE: strncpy being related the DIRSIZ

I do not think so, certainly not my memory of programming at the time.
 Back then, many other languages I was using such as SAIL and some of the
Algol family had similarly named functions.  I wish he were still with us
to ask, but I really think that when Dennis rewrote the V5/V6 "portable C
library" into what would become stdio and friends, adding the str*.c family
was natural - all the other cool kids had one and it was just a
convenient function
when we all were writing code for C to have it also.

This is pre "white book" (aka V5 & 6) but I have definite memories of the
late Ted Kowalski teaching me what function libraries that were available
for C.  One of my first programs (after helping Ted with fsck) was
rewriting a SAIL based 6502 assembler in C and needing string functions.
I have distinct memory of b*tching to Ted about having to write my own
string functions.

By the mid-late 70s a number of "ctools"or "c libraries" would appear from
UCB, CMU, MIT et al with many of the same basic functions just with
slightly different parameters.  Go look in the old USENIX tapes, you should
see the same stuff getting recreated in many places.

Clem


On Tue, Jan 22, 2013 at 11:03 PM, Nevin Liber <nevin at eviloverlord.com>wrote:

> On another list I am on, a discussion about the history and purpose of
> strncpy has arisen.  The only reference I have found to it is <
> http://lwn.net/Articles/507432/>:
>
> The original reason for strncpy() was when directory names were limited to
> 14 chars. The other two bytes contained the inode number. For that
> particular case, strncpy() worked quite well.
>
> Is that really the reason it came into being?
>
> Just a bit curious,
> --
>  Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com>  (847) 691-1404
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130123/0b64e705/attachment.html>

[TUHS] History of strncpy

[Ronald Natalie]

I agree with uh Clem.   First off, Nevin's rememberence is wrong.   The I-node number was the first two bytes of the V6 directory entry followed by a FIXED 14 spaces for the name (null terminated or not depending on whether the length was there).

I can guarantee there was no STRNCPY in the kernel, and my memory is with Clem, the V6 and even the phototypesetter versions of the C compiler and libraries didn't have these functions.
By the time Version 7 rolled around, the variable length directories had also appeared in the filesystem.    I suspect strcpy arrived with the "portable I/O library", an abomination that eventually evolved into the stdio library and to this day is still stinking up the standard C language.

Amusingly, removing a file only zeroed out the inumber field.   This could lead the creative hacker to leave all sorts of fun messages in the directory by creating and removing files carefully.
We had an alternate shell that was removed for security reasons and one day I found if you did "cat /tmp" there was some noise at the top for the current user of it but then a bunch of new lines and a message that said "Looking for a ghost of nosh?"

[TUHS] History of strncpy

[Armando Stettner]

I also second/support Ron's and uh Clem's view.  In addition to zeroing out the inumber field, "removing" a file decremented the reference count in the i-node causing it to be freed (not cleared) when the reference count went to zero.  There was no strncpy() in the kernel.  Was there a strcpy() (other than a macro) in the kernel??  Long live movtuc.

Begin forwarded message:

> From: Ronald Natalie <ron at ronnatalie.com>
> Subject: Re: [TUHS] History of strncpy
> Date: January 23, 2013 9:01:04 AM CST
> To: Clem Cole <clemc at ccc.com>
> Cc: tuhs at minnie.tuhs.org
> 
> I agree with uh Clem.   First off, Nevin's rememberence is wrong.   The I-node number was the first two bytes of the V6 directory entry followed by a FIXED 14 spaces for the name (null terminated or not depending on whether the length was there).
> 
> I can guarantee there was no STRNCPY in the kernel, and my memory is with Clem, the V6 and even the phototypesetter versions of the C compiler and libraries didn't have these functions.
> By the time Version 7 rolled around, the variable length directories had also appeared in the filesystem.    I suspect strcpy arrived with the "portable I/O library", an abomination that eventually evolved into the stdio library and to this day is still stinking up the standard C language.
> 
> Amusingly, removing a file only zeroed out the inumber field.   This could lead the creative hacker to leave all sorts of fun messages in the directory by creating and removing files carefully.
> We had an alternate shell that was removed for security reasons and one day I found if you did "cat /tmp" there was some noise at the top for the current user of it but then a bunch of new lines and a message that said "Looking for a ghost of nosh?"
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 

[TUHS] History of strncpy

[scj]

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!

[TUHS] History of strncpy

[Ronald Natalie]

Decrementing the reference count in the inode also cleared an allocated bit in the flags (unless it was held open after deleted).    It also added it to an ersatz-free list of 100 entries, but unlike the disk freespace, that didn't have a provision to link to more entries.   After the inode freetable was exhausted, the inodes were scanned to find more free ones to replenish the list.

The original v6 filesystem code wasn't very transaction safe.   When the machine crashed, you can almost count on a file in the process of deletion having either a mismatched number of appearances in directories versus the reference count in the inode.    The program "dcheck" was run to reconcile these.    Of course, dcheck only reported the errors.   Fixing them was more fun (especially since fsdb was yet to be written).    Any files that were open but deleted would be left allocated with 0-0 link count and references.     A program "clri" would zero out the entire inode for these files to fix that.   Of course, that's a bit brute force (and hard to reverse if you screwed up and did the wrong one).    We rewrote it to only reset the allocated bit.

The kernel didn't have any string functions either.   Namei (the function that handles mapping file names to inodes) just used char*'s to traverse, compare, and copy the strings.   The code that handled the arguments for exec did the same.   m45.s where many assembler utility functions lived had some block copying (although they are not heavily used by the C code which just as soon would copy things with loops)  but nothing that knew anything about strings.

On Jan 23, 2013, at 10:24 AM, Armando Stettner wrote: 

> I also second/support Ron's and uh Clem's view.  In addition to zeroing out the inumber field, "removing" a file decremented the reference count in the i-node causing it to be freed (not cleared) when the reference count went to zero.  There was no strncpy() in the kernel.  Was there a strcpy() (other than a macro) in the kernel??  Long live movtuc.
> 
>> 

[TUHS] History of strncpy

[Ronald Natalie]

I did some searching and the previous answer is correct.   Neither V6 or PWB 1 have any of the str functions.    V7 and 32V both have them (including strncpy).
I was wrong in my conjecture it came over with the portable (later to be std) io library.   It seems to have happened in the revamping of libc into seperate subdirectories.

[TUHS] History of strncpy

[Clem Cole]

On Wed, Jan 23, 2013 at 2:33 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

> It seems to have happened in the revamping of libc into seperate
> subdirectories.


Tanks Ron - that makes sense.

As I said, there were functions like that in other languages, plus their
was beginning to be a number of library toolkits for C that people were
cons-ing up in that timeframe --> particularly by stripping helper routines
from other programs.   Horton & Joy's termcap and eventually curses came to
live that way.

I just did a little searching of my own code archives and sure enough I
found a file called support.c that has the functions len, copy and comp in
it, which I must have used pre-V7  {code's ugly too - so it was clearly
early C for me - I was still fighting the one-true-brace-style having come
over from SAIL, Algol and BLISS}.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130123/88ca3f80/attachment.html>

[TUHS] History of strncpy

[Mary Ann Horton]

While I agree with the other excellent comments in this thread (I just 
dig out my document for the original "Portable C Library (on UNIX)", 
complete with functions beginning with "C"), I have one small correction.

Variable length file names in directories actually didn't come out until 
the Berkeley Fast Filesystem in 4BSD.  They were not in V7 or even 3BSD.

> By the time Version 7 rolled around, the variable length directories had also appeared in the filesystem.    I suspect strcpy arrived with the "portable I/O library", an abomination that eventually evolved into the stdio library and to this day is still stinking up the standard C language.
>
>

[TUHS] History of strncpy

[Clem Cole]

Not to put too fine a point on it, Kirk's filesystem does not show up in
the mainstream outside of Berkeley until 4.2BSD IIRC mid 1984.   4.1 was
still based on the V7/TSS file systems [inside UCB we had 4.1A, 4.1B, 4.1C
- although if my memory serves me 4.1C was semi-available - I know I took
it Masscomp, SUN had it, and Armando you must have had it at DEC].

Anyway, the post 4.1 BSD system was when Fast File systems and Berkeley
directory system calls were added, to make some of the operations atomic
and the user space code more portable.

Henry Spencer's famous quip in the early 1980s:  *"**4.2BSD does everything
UNIX does, only differently."*
*
*
Looking back on it, ideas like the VFS layer would take a few years more.
 But without moving the directory specifics out of user space code like it
was V7 and earlier, it would have been hard to create something as clean as
VFS.


On Wed, Jan 23, 2013 at 5:43 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> While I agree with the other excellent comments in this thread (I just dig
> out my document for the original "Portable C Library (on UNIX)", complete
> with functions beginning with "C"), I have one small correction.
>
> Variable length file names in directories actually didn't come out until
> the Berkeley Fast Filesystem in 4BSD.  They were not in V7 or even 3BSD.
>
>
>  By the time Version 7 rolled around, the variable length directories had
>> also appeared in the filesystem.    I suspect strcpy arrived with the
>> "portable I/O library", an abomination that eventually evolved into the
>> stdio library and to this day is still stinking up the standard C language.
>>
>>
>>
> ______________________________**_________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/**mailman/listinfo/tuhs<https://minnie.tuhs.org/mailman/listinfo/tuhs>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130123/95688214/attachment.html>

[TUHS] History of strncpy

[Jonathan Gevaryahu]

I don't know about strncpy but strcmp appears (not under that name but 
with identical functionality) in speak.c from 1973ish...

On 1/22/2013 11:03 PM, Nevin Liber wrote:
> On another list I am on, a discussion about the history and purpose of 
> strncpy has arisen.  The only reference I have found to it is 
> <http://lwn.net/Articles/507432/>:
>
> The original reason for strncpy() was when directory names were 
> limited to 14 chars. The other two bytes contained the inode number. 
> For that particular case, strncpy() worked quite well.
> Is that really the reason it came into being?
>
> Just a bit curious,
> -- 
>  Nevin ":-)" Liber  <mailto:nevin at eviloverlord.com 
> <mailto:nevin at eviloverlord.com>> (847) 691-1404
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


-- 
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20130123/a87489b2/attachment.html>