[Coco] Os9 Intercept

[Bill Pierce]

@Lothan
The only problem I'm going to run into using write() or writeln(); is that I have to define every string or load a variable with the string so that I can get a string length. This turns

"printf("This is a string");

into

strg = "This is a string"
write(STDOUT,strg,sizeof(strg);

And with over 200 "printf"s already in place and more coming, it's going to be a task plus making my sources larger. I don't know if setting up the string takes any more space after compiling than stating it in a printf.

Bill P

Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Bill Pierce
ooogalapasooo at aol.com




-----Original Message-----
From: Lothan <lothan at newsguy.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Tue, Oct 30, 2012 12:50 pm
Subject: Re: [Coco] Os9 Intercept


You have a few ways to tackle this.

If you are using the high-level I/O function calls (puts, printf, etc.) on a 
file descriptor, you can effectively disable buffering by setting a flag in 
the FILE structure. This may not even be documented anywhere and it's been 
years since I've played with it so I don't remember the details. If you poke 
around the FILE structure members, I think the one you want to set should be 
fairly obvious and you'll need to set it immediately after you open the path 
and before you perform any I/O on that path. If I remember correctly, the 
standard paths (stdin, stdout, stderr) are unbuffered by default but any 
paths you open with a call to fopen() or fcreat() are buffered... assuming 
I'm remembering correctly.

In my opinion, the best alternative is to avoid using the high-level I/O 
function calls and go straight to the low-level I/O function calls: read(), 
readln(), write(), and writeln() are implemented in assembly and are 
straight calls to I$Read, I$ReadLn, I$Write, and I$WritLn without any 
overhead or fancy-schmancy finagling or buffering.