From: imp@bsdimp.com (Warner Losh)
Subject: [TUHS] History of strncpy
Date: Thu, 31 Jan 2013 17:06:26 -0700 [thread overview]
Message-ID: <56033419-2AFA-4E3D-ADB6-261B1B79B55B@bsdimp.com> (raw)
In-Reply-To: <510B03B6.6010708@fastmail.us>
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
next prev parent reply other threads:[~2013-02-01 0:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
-- strict thread matches above, loose matches on Subject: below --
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
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
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=56033419-2AFA-4E3D-ADB6-261B1B79B55B@bsdimp.com \
--to=imp@bsdimp.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).