[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