[Tutorial] File I/O

[SG57]

...hmm... off topic, but does the KKK have a symbol?  Or is it there whitehoods?  

anyway, so is the retro 80s piece sign  it signifys alot of things...

[whazilla]

i think it's hoodwinked

and oh yeah ... a cross witha circle ... reminds of a playstation symbol :p

[Raphael]

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.

Why are you casting malloc() ?

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.

[Raphael]

Well, he's young and wants to show-off, nothing else. And it works with anyone that has no clue about programming, but I only find myself grining. He has to learn that he's not yet good enough to talk so big.

[SG57]

harleyg - you didnt back your code up Raphael did, so you dont have any room to talk...

Raphael - yes im young still, (14), so sue me...  Im trying and you have to admit, i made 'some' very good points for my age (?)...  Oh and to follow the 'recommeneded' usage of the libraries prototypes is a well thoguht out strategy becasue it gives you a good habit, where as, as an example, declaring ftell() as an 'int' will only work in those special cases you said already...

Anyway, glad that's all cleared up.

[Raphael]

Raphael - yes im young still, (14), so sue me...  Im trying and you have to admit, i made 'some' very good points for my age (?)...

I'm not sueing you for being young. Everyone was young once, the only difference is that some understand that their still limited experience and knowledge isn't enough to talk big and play smartass, while the others always try to do exactly that, though most of the time they just make a fool of themself. Unfortunately, you have tendencies to the latter.
Noticing such small inconsistencies to the definitions is a very good attribute for a future programmer and shows potential, but you need to get 100% sure that you're right before shouting 'you made a mistake!', especially if you still make very basic mistakes yourself (like on your other threads here and on PSPU/PS2Dev). That's just some wanna-be attitude, exactly as giving yourself big titles.

Oh and to follow the 'recommeneded' usage of the libraries prototypes is a well thoguht out strategy becasue it gives you a good habit, where as, as an example, declaring ftell() as an 'int' will only work in those special cases you said already...

Its correct to start from ground up with building a good programming habit for oneself. However, trying to tell others their programming habit is wrong/bad because it differs from your own is a bad social habit.
And these ftell cases aren't that special at all, it's rather the other way around, since we're on a psp-programming forum here.

In the end, it all just comes down to the way how you put down your ideas/criticism. You can try to be constructive and give hints on how to improve things and this will absolutely be accepted and also appreciated. However in your case it just sounded like you were trying to pick upon harleyg and that's something I don't like, and even more so when the picking isn't correct either.

I think you can become a good programmer once, but you need to get rid of your cheeky attitude, or else you won't be accepted by the better programmers, and only from them you can learn and get better yourself.

[SG57]

harleyg - Seeing as how my age keeps coming up so many times with my programming techniques (I wasn't planning on bringing my age up), I'd say I can use my age as an excuse...

Raphael - I wasn't being a smart ass or anything, I even said to not get mad, but when I looked through and saw some things wrong in the code, I posted what I had seen...  Also, harleyg had said himself that this is 'general' C and yeldarb had just converted it to match PSP Specific I/O Standards to use in the tutorial...  So yes, Id say since this 'thread' is pretty much only General C, ftell()'s return value should be a long, which is important for use on cross-platforms.

[gamehunter101]

Lets just all respect each other and chill alittle  

[Raphael]

ftell()'s return value should be a long, which is important for use on cross-platforms.

Well, technically ok, but it's still not really wrong to cast it to int there, it will only return wrong filesizes/file positions when above 2Gb. I don't think that is something beginners are working with, exactly like cross-plattform compatibility
But I don't wanna argue any more on this, I just wanted to give you my opinion on some of your attitude in the last post.

[SG57]

So yes, Id say since this 'thread' is pretty much only General C, ftell()'s return value should be a long, which is important for use on cross-platforms.

Try again harleyg.

Do you really want to start all this again?

[Waterbottle]

I'm not sure if I should ask this here..  But I guess it involves fileI/O so I'll do it here:

How can I read what a files timestamp is?

[Insert_Witty_Name]

I'm not sure if I should ask this here..  But I guess it involves fileI/O so I'll do it here:

How can I read what a files timestamp is?

I was interested in this too so I gave it a go.

I made an example that worked perfectly on the PC - but gave incorrect date/time on the PSP.

This link contans everything you need to know - plus an example program.

http://cermics.enpc.fr/~ts/C/FUNCTIONS/stat.html

I'm sure it's probably me - I've just got home from a 12 hour night shift, so I could be a little tired  

[ai3gtmc]

the links for the I/O are down

[gb009]

Hi,

I get the following error when I try to compile the first program in this tutorial:
$gcc main.c
/cygdrive/c/DOCUME~1/gb/LOCALS~1/Temp/ccCFKDIk.o:main.c:(.text+0x6a): undefined reference to '_fseel'
collect2: ld returned 1 exit status



I am posting the code below:
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
   FILE *pFile;
   long lSize;
   char * buffer;

   pFile = fopen("myfile.txt", "rb");

   if(pFile==NULL)
   {
      exit(1);
   }
   fseel(pFile, 0, SEEK_END);
   lSize = ftell(pFile);
   rewind(pFile);

   buffer = (char*) malloc (lSize);
   if(buffer == NULL)
   {
      exit(2);
   }

   fread(buffer,1,lSize,pFile);

   fclose(pFile);

   printf("%s\n", buffer);

   free(buffer);

   return 0;
}


what i am using:
Cygwin with PSPSDK.

command used to compile : gcc main.c

[BigBlack]

The Problem is here":

Code:

   fseel(pFile, 0, SEEK_END);

It Should be:

Code:

   fseek(pFile, 0, SEEK_END);

  It's an understandable typo.