This also seems to work fine:
void readFile2(const char *filename)
{
char buf[200];
FILE *fp = fopen( filename, "r" );
if (fp)
{
fgets(buf, 100, fp);
fclose(fp);
printf("data: %s\n", buf);
}
}
File pointers in CC65!
File pointers in CC65!
This also seems to work fine:
File pointers in CC65!
52 minutes ago, rje said:
This also seems to work fine:
cprintf("data: %s\r\n", buf);
You should use
printf();
in an example about stdio code.
File pointers in CC65!
2 hours ago, Greg King said:
You should use
printf();
in an example about stdio code.
Updated.
It is messy, isn't it? CC65 pushes conio to us, and yet stdio is... well, stdio. The reality is that my code is always a work in progress.
File pointers in CC65!
On 8/11/2021 at 9:43 AM, rje said:
@Greg King, would it be wrong for me to add timestamp fields to cbm_readdir? I know most CBM devices don't read or write timestamp, but the directory entries have space for it, and it's used in the later drives, so....
...and I've found the answer: no. Reading $ means reading the "directory file" built by LOAD. If that thing doesn't include timestamp, then this one won't ever see it.
-
Scott Robison
- Posts: 952
- Joined: Fri Mar 19, 2021 9:06 pm
File pointers in CC65!
29 minutes ago, rje said:
Updated.
It is messy, isn't it? CC65 pushes conio to us, and yet stdio is... well, stdio. The reality is that my code is always a work in progress.
It really depends on what you're trying to do. cprintf is not part of standard C, but it is offered by many platforms. And it doesn't have the potential overhead of processing data as a file stream, so it can be (not that it is guaranteed to be) faster when you *know* you want to write to the screen and not whatever is pretending to be the standard output stream.
File pointers in CC65!
Not to mention (although you hinted at it) that avoiding printf can shrink the binary size.
-
Scott Robison
- Posts: 952
- Joined: Fri Mar 19, 2021 9:06 pm
File pointers in CC65!
7 minutes ago, rje said:
Not to mention (although you hinted at it) that avoiding printf can shrink the binary size.
True, though I suspect avoiding printf by using cprintf probably doesn't help the binary size much. I would think that they both use the same formatting code underneath and the only real difference is whether the screen is targeted or a file stream pointer.
If they do not share the exact same formatting code, then that only makes things worse, especially on memory constrained 8 bit platforms!
File pointers in CC65!
It's actually a thing. I checked out the memory dump files created by cc65 and I could see how many bytes are used by the presence of each function... and while a function might be only a few hundred bytes... well, it can add up.
/Users/rje/git/cc65/lib/cx16.lib(_printf.o):
CODE Offs=003D6C Size=0003A5 Align=00001 Fill=0000
BSS Offs=000359 Size=00002B Align=00001 Fill=0000
DATA Offs=0000FA Size=000003 Align=00001 Fill=0000
933 bytes...
Meanwhile, cprintf is different...
/Users/rje/git/cc65/lib/cx16.lib(cprintf.o):
CODE Offs=004299 Size=00002A Align=00001 Fill=0000
BSS Offs=000384 Size=000001 Align=00001 Fill=0000
Tiny. As you suggest, perhaps it has its string formatter in a utility function... but printf has some extra oomph.
In short, if I replace the printf's with cprintf, then I get a 900 byte reduction.
File pointers in CC65!
"(_printf.o)" is the common formatter function that everything uses.
"(printf.o)" has the printf() function. But, it calls "(vfprintf.o)", which calls "(fwrite.o)", which calls "(write.o)".
File pointers in CC65!
I was wondering what the difference was. I know that in cc65, cprintf() fails to scroll the screen and interprets \n as CR whereas printf() scrolls and interprets \n as CRLF. cprintf could probably stand to be fixed in its cx16 implementation....