23 Jan
2013
23 Jan
'13
5:56 p.m.
Ronald Natalie <ron(a)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
23 Jan
23 Jan
9:08 p.m.
New subject: History of strncpy
On Wed, Jan 23, 2013 at 05:56:14PM +0000, Michael Spacefalcon wrote:
Ronald Natalie <ron(a)ronnatalie.com> wrote:
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
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... 
9:39 p.m.
New subject: History of strncpy
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs 
9:46 p.m.
New subject: History of strncpy
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(a)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
24 Jan
24 Jan
6:02 a.m.
New subject: History of strncpy
On Wed, Jan 23, 2013 at 04:46:51PM -0500, John Cowan wrote:
Ronald Natalie scripsit:
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
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. 
6:34 a.m.
New subject: History of strncpy
On Wed, 23 Jan 2013, Larry McVoy wrote:
On Wed, Jan 23, 2013 at 04:46:51PM -0500, John Cowan
wrote:
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.
Ronald Natalie scripsit:
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).
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.
2:42 p.m.
New subject: History of strncpy
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.
2:52 p.m.
New subject: History of strncpy
On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
On Jan 24, 2013, at 1:02 AM, Larry McVo
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
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 mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
4:01 p.m.
New subject: History of strncpy
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.
4:21 p.m.
New subject: History of strncpy
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(a)bsdimp.com> wrote:
On Jan 24, 2013, at 7:42 AM, Ronald Natalie wrote:
On Jan 24, 2013, at 1:02 AM, Larry McVo
library that an implementation can do
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 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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
6:31 p.m.
New subject: History of strncpy
Ronald Natalie <ron(a)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
25 Jan
25 Jan
2:06 a.m.
New subject: History of strncpy
On Jan 24, 2013, at 11:31 AM, Tom Ivar Helbekkmo wrote:
Ronald Natalie <ron(a)ronnatalie.com> writes:
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
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. :) 
31 Jan
31 Jan
11:52 p.m.
New subject: History of strncpy
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".
1 Feb
1 Feb
12:06 a.m.
New subject: History of strncpy
On Jan 31, 2013, at 4:52 PM, Random832 wrote:
On 1/24/2013 9:52 AM, Warner Losh wrote:
VAXC would crash and burn, signaling your programming error if you dared try to do this.
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".
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
12:28 a.m.
New subject: History of strncpy
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
4102
days inactive
4111
days old
14 comments
9 participants
participants (9)
-
Clem Cole -
John Cowan -
Larry McVoy -
msokolov＠ivan.Harhan.ORG -
Random832 -
Ronald Natalie -
Steve Nickolas -
Tom Ivar Helbekkmo -
Warner Losh