...and another thing! </JeremyClarkson> At 2024-01-18T01:22:53+1100, John Gardner wrote: > I'll probably need you to review any shims I write for any C89+ > stdio(3) functions that don't exist in V7's C compiler (which is > surprisingly limited)…
You might consider, as an initial step, just not bothering with stdio.
As I understand it, the standard I/O library was developed to serve two
goals: optimization and abstraction. When using the kernel's I/O system
calls read() and write(), to be performant one had to be aware of the
"block size" of block devices, and it was indeed ridiculous to impose
this responsibility on every application.
But performance is _not_ a consideration for a reimplemented cat2dit
until and unless we get frustrated by the lack of it. I certainly
wouldn't go to the trouble of reimplementing popen(3) to get this job
done. If I were biting off the task, I'd just pipe "troff -t" output to
your program, read(2) the standard input file descriptor a byte a time,
and write(2) to the standard output.
Much of my programming career has been a repeated series of lessons
(acquired sometimes to my chagrin) in decomposing problems into almost
ridiculously small components. Examples of questions I have taught
myself to ask are "what is the simplest thing that could possibly work?"
and "what is the smallest change that constitutes progress toward the
goal?" (Actually, the first of those was spoken to me by one of the
_good_ managers I've had--a light bulb moment in my 20s.)
Some people, I am sure, intuitively grasp this principle even as novices
(to great success _if_ they can keep managers or sales personnel from
flinging something out the door before it's been documented, validated
with a test suite, and made robust[1]).
But me, I had to _learn_ how to eat an elephant.
One bite at a time.
Regards,
Branden
[1] "MVP: Minimum Viable Product" is an example of a much-abused
buzzword. The popular approach is to focus on "minimum" and
"product" while neglecting "viable", which literally means "capable
of living". Then people wonder where "technical debt" comes from.
signature.asc
Description: PGP signature
