Before being picky, better first do some deeper research...
File Input (Reading) - 3. Searching to a certain point.
... i hate to say this harleyg, (cause u hate me enough) but...
ftell() returns a long - you have it as an integer.
For the PSP and any 32bit machine, int and long have the same size, so it doesn't matter. If this would be compiled for a 64bit architecture and run on a 64bit OS, it makes only little difference, because only filesizes up to 2Gb will be returned correctly. Well... nothing I would care about in a program where I know how big my files can be.
Actually, casting malloc isn't wrong (esp. on PSP, since malloc is correctly returning void*). If you read through your posted thread more closely, you will see that it also has some specific advantages depending on programming style. And the latter is something that everyone has to choose for himself. In fact I cast malloc sometimes myself.
Why are you stuffing
EOF into a char and not an int?
First, the link you give has absolutely nothing to do with the EOF returned by fgetc in C, it references the function eof in the TCL language. In stdio.h EOF is defined as -1, and as such can be held by a char. So this is absolutely legal, though not 100% correct (it could still be the case, though not very likely, that there is character with value -1 (0xff hex) in the file, which will cause the loop to end prematurely).
Also see sample code from
http://www.cplusplus.com/ref/cstdio/fgetc.html
Why are you declaring a variable that you don't use (n)?
This is something that always happens to everyone, when revising one's code, for example when cleaning up for a tutorial or public release. If you would have some more experience, you would know this.
Why isn't there room for the NULL character?
This one is the only one really important criticism. It would be enough to just set buffer[size-x] = '\0' after the read, but kill the last byte.
Not much left of your criticism in the end.
