From mboxrd@z Thu Jan 1 00:00:00 1970 From: imp@bsdimp.com (Warner Losh) Date: Thu, 31 Jan 2013 17:06:26 -0700 Subject: [TUHS] History of strncpy In-Reply-To: <510B03B6.6010708@fastmail.us> References: <1301231756.AA27240@ivan.Harhan.ORG> <20130123214651.GF22559@mercury.ccil.org> <20130124060205.GQ24498@bitmover.com> <1AFADE66-7F72-4776-8738-EC27748DAF33@ronnatalie.com> <510B03B6.6010708@fastmail.us> Message-ID: <56033419-2AFA-4E3D-ADB6-261B1B79B55B@bsdimp.com> 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